setting aside SAMPLE_EVENT_xxx ranges for applications

[Jef Driesen]

On 2014-05-06 16:12, Dirk Hohndel wrote:
> On Tue, 2014-05-06 at 16:00 +0200, Jef Driesen wrote:
>> >>> b) you add a reserved range of numbers that we can simply redefine
>> >>> SAMPLE_EVENT_APP_RESERVED_1
>> >>> ...
>> >>> SAMPLE_EVENT_APP_RESERVED_8
>> >>> (or some reasonable number)
>> >>> Then we can do a
>> >>> #define SAMPLE_EVENT_SUBSURFACE_SP_CHANGE SAMPLE_EVENT_APP_RESERVED_1
>> >>> and all is well.
>> >>> What do you think?
>> >>
>> >> I'm not convinced this should be addressed with a change in
>> >> libdivecomputer. The right solution would be to define your own set of
>> >> events, and translate the libdivecomputer events to the corresponding
>> >> subsurface events. Why should other applications have to deal with
>> >> subsurface specific events? Imagine the mess we would end up with, if
>> >> all other applications start to request their own events too.
>> >
>> > Which is why I suggested SAMPLE_EVENT_APP_RESERVED_xx - so any app can
>> > use those as needed.
>> 
>> But then we introduce some unnecessary limit for libdivecomputer. 
>> Assume
>> we set SAMPLE_EVENT_APP_RESERVED to 255. That's probably plenty of 
>> room
>> for future events. But if we ever need more (unlikely, but who knows),
>> then I can't add more. Unless I change SAMPLE_EVENT_APP_RESERVED, and
>> break applications. So that's a bad solution for everyone.
> 
> I am obviously not making myself clear.
> 
> What I suggested was to have a handful of event numbers reserved. So
> after SAMPLE_EVENT_GASCHANGE2 you could add 
> SAMPLE_EVENT_APP_RESERVED_1,
> SAMPLE_EVENT_APP_RESERVED_2,... and then if you need the next event for
> a new divecomputer you add it AFTER those values. That way it is future
> proof, no arbitrary maxima, etc.

Sorry, I misunderstood. Regardless, my other concern remains valid. Why 
add some value that serves no purpose for libdivecomputer itself? Am I 
the only one that finds this a little odd?

> YOUR proposal was that I should randomly assume some maximum value and
> use a high bit - THAT is what would possibly end up badly.
> 
> That is EXACTLY why I suggested NOT to do that and to have you reserve 
> a
> few numbers that applications can use for their own purposes.

Well, my proposal was actually to properly map the libdivecomputer 
events to independent subsurface events. Setting the high bit was just a 
suggestion for a quick short-term solution.

> It's simple, it's obvious, everyone gets to use them which ever way 
> they
> want, and no future change in libdivecomputer will ever break this.

What if you need more than X reserved values in the future? Of course we 
can just add more reserved values to libdivecomputer. But then you are 
blocked until the next libdivecomputer release is available.

I'm still not convinced this is the best solution.

>> > Maybe you are right - we need to rip out the libdivecomputer event
>> > model and create our own and simply populate it from the data
>> > libdivecomputer provides us.
>> > That way we can deal with some of the other annoyances that we have
>> > inherited from libdivecomputer as well
>> 
>> I think that's the only correct solution.
> 
> That is one of many correct solutions. And I guess it's the one I'll
> take.

I should have said "more correct" instead of "only" :-)

Jef