setting aside SAMPLE_EVENT_xxx ranges for applications

[Jef Driesen]

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.

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.

Jef