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
