ideas for representing repetitive dives

[Jef Driesen]

Giorgio,

Sorry for the late response. I have been a bit occupied with other 
things the past few weeks.

I don't think libdivecomputer provides only a "least common denominator" 
experience. The majority of the information (and if you ask me, also the 
most interesting info) is common between all dive computers. We're 
talking about general info like the date/time, maxdepth, divetime, and 
of course the sample data. Those are the features that are supported 
today. There is no doubt room for improvement here, but I think we 
already cover quite some info.

You are absolute right that most devices also provide some additional 
info that is not supported by libdivecomputer at all. There are two 
reasons for that. Usually not only the encoding, but also the data 
itself is highly device specific. That makes it rather difficult to 
support it through a common device independent api. The other reason is 
a more practical one. I only have a limited amount of time available, so 
I try to spend it on those features that benefits most users, instead of 
some exotic feature that only a few users care about.

My point of view is that if you want to squeeze out every single bit of 
information, then you're probably better of with a device specific 
application (like the one from the manufacturer), instead of a general 
purpose application.

Having said all that, I'm not saying no to the idea of vendor specific 
additions, if it doesn't have a major impact on the rest of the api, but 
it's definitely not at the top of my priority list.

Going back to the subdives topic, I'm not convinced supporting such a 
concept can be implemented without a major impact on the rest of the 
api. Altering the behavior of the api, depending on whether the 
application enables some special subdive mode, is also not my favorite 
option. Having two separate code paths will make the api more complex 
and harder to maintain.

Right now the two approaches that seems to make the most sense to me is 
to:

1. Merge all subdives into one large dive. That's basically what we are 
doing now. The main disadvantage in your particular case, is the we 
loose the min/max temperature of each subdives. We can't use the 
DC_FIELD_XXX api here (because that's per dive) and we can't use the 
sample temperature either (because we don't know at which sample the 
min/max temperature was measured).

2. Deliver each subdive separately. Since each subdive is now a separate 
dive we can use the DC_FIELD_XXX api for the min/max temperature. The 
main drawback here might be the large amount of very short dives. But on 
the other hand, applications can easily group (free)dives again based on 
the date/time information. Similar to how subsurface does group dives 
into trips. If necessary we can always introduce a new field containing 
the index in the subdive session to assist there. Some dive computers 
have a similar concept for scuba dives: the repetitive dive number.

These two options is also how most other dive computers record 
freedives: record one large dive covering the entire freedive session, 
or record each freedive in the session as a separate dive. The 
difference usually depends on the depth and/or surface time thresholds 
of the dive computers. A short surface time threshold will result in 
individual dives, while a larger threshold will result in one large 
dive.

(I already discussed the above with Giorgio, but for the mailing list it 
will be useful to provide some more context.)

Jef

On 2015-10-26 10:43, Giorgio Marzano wrote:
> Hi,
> 
> I didn’t had much spare time in the last weeks, but I kept thinking 
> about
> the idea of representing repetitive dives on libdivecomputer
> 
> 
> Initially I wrote a simple spreadsheets to summarize the pros and cons 
> of
> 
> possible
> 
> approaches
> 
> . Colors represents the “severity” of a drawback or of an impact and 
> are my
> guesses.
> 
> We may use it to confront ideas.
> 
> Generally speaking I think that the API
> 
> should really
> 
> include a way to pass free-form data to the
> 
> app, while right now everything is codified in the "least common 
> multiple"
> of all the DC capabilities.
> 
> It may seems a weird thing to do, but consider that
> 
> each dc may have specific information which the
> 
> user (who chooses and bought that DC)
> 
> may want to be represented on the profile.
> 
> I am thinking about alarms and statistics, and also the whole “subdive”
> stuff.
> 
> 
> It could be a good idea to introduce some kind of USER_EVENT (or
> USER_SAMPLE) with name, type (int, float, bool, string) and value 
> fields.
> 
> Parsers should use the USER_EVENT to report info which the app may 
> choose
> to skip, draw as it is or elaborate.
> 
> 
> Then we may define policies on such events. Such that 'alarms name 
> shall
> start with "AL_'" or similar to hint the apps.
> 
> 
> This would be, in my opinion, a
> 
> progressive and
> 
> low-impact
> 
> way
> 
> to improve flexibility of the API.
> 
> Referring to the attached table, such change would allow for a simple a
> straight forward implementation of the workaround
> 
> for the drawbacks of the “Merge Subdives” approach or for the whole 
> “report
> session and dives in an unstructured way” stuff.
> 
> 
> 
> Let me know what do you think about it.
> 
> G