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