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
