On 2014-05-06 15:21, Dirk Hohndel wrote:
On May 6, 2014, at 2:22 AM, Jef Driesen jef@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