setting aside SAMPLE_EVENT_xxx ranges for applications

[Jef Driesen]

On 2014-05-06 15:21, Dirk Hohndel wrote:
> On May 6, 2014, at 2:22 AM, Jef Driesen <jef at libdivecomputer.org> 
> wrote:
> 
>> On 2014-05-05 18:36, Dirk Hohndel wrote:
>>> chasing a bug in Subsurface today I realized that we are abusing
>>> existing event types internally since we don't have reserved event 
>>> types
>>> that we know will not be used by libdivecomputer in the future.
>>> I guess there would be two solutions:
>>> a) we ask you to add events that you haven't seen in any dive 
>>> computer,
>>> yet, so we can use them as synthetic events for our own purposes (so 
>>> far
>>> this is only a "setpoint change" event that we use in the planner).
>>> 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.

>> Having said that, I think the easiest way to keep abusing the 
>> libdivecomputer events (e.g. a direct one-to-one mapping) and add some 
>> application defined events as well, is to set some high bit for your 
>> application specific events. Right now, the highest value is 25 
>> (SAMPLE_EVENT_GASCHANGE2) and that value is very unlikely to ever grow 
>> past an 8 or 16 bits value.
> 
> And no one will ever need more than 640k RAM.

Let's say, that by the time we need all 32 bits (about 16M possible 
values) for the events, I probably lost my sanity already :-)

It's already a mess with just 25 events.

> 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.

Jef