No subject

[Giorgio Marzano]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20151026/f670c602/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DiveSession.ods
Type: application/oleobject
Size: 18236 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20151026/f670c602/attachment-0001.bin>