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