setting aside SAMPLE_EVENT_xxx ranges for applications

[Jef Driesen]

On 2014-05-06 19:57, Linus Torvalds wrote:
> On Tue, May 6, 2014 at 10:44 AM, Jef Driesen <jef at libdivecomputer.org> 
> wrote:
>> 
>> How is that different from what we have today? If libdivecomputer gets 
>> some
>> new event today, then subsurface will not be able to use it, until 
>> some code
>> is added to handle it properly.
> 
> Sure it can. We may not know what it is, but we can still save the
> event number and data, and at least it's there. And this is not
> theoretical. We've done this.
> 
> If we use some totally disjoint "these are our events", we can't do 
> that.
> 
> This is the *only* reason we use that horrid type/flags/value model in
> the first place. But it's a big reason. And you just seemed to totally
> dismiss it.

I didn't realize Subsurface stored the event data as-is. I just looked 
at the handle_event function where the event type gets translated into 
the corresponding event name. So that's why I assumed subsurface does 
already map the event to something else. I just didn't notice you also 
keep the event type around (and save it to the xml too). So yes, you are 
right on that. My apologies.

Anyway, I think your suggestions of adding an extra bit to distinguish 
between a libdivecomputer and a subsurface specific event is a better 
solution than introducing some reserved value(s) in libdivecomputer. 
Then you can have as many internal events as you need, without needing a 
dependency on libdivecomputer.

Jef