Subsurface and rebreather dive logs.

[Dirk Hohndel]

Why didn't you send this to subsurface? I took the liberty to add the
list so everyone gets to see the conversation.

On Mon, 2014-04-21 at 12:35 +0200, Willem Ferguson wrote:
> Dirk,
> 
> Miika, Tomaz and myself are now getting towards implementation of 
> rebreather dive logs on Subsurface. This is NOT for V4.1. I have a few 
> questions.
> 
> 1) I have been messing around with the sample and divecomputer 
> structures, defined in dive.h. This adds five integer variables to the 
> sample structure and another one to the divecomputer structure. Is there 
> any possibility that adding these variables may have large memory 
> requirement implications? I should not thinks so, since a divecomputer 
> structure with 5000 samples (a pretty long dive) will have less than 
> 25000 additional integers. But I do not have a system-wide perspective.

5 integers to the sample is making that structure more than 1/3 bigger.
But unless you are on a system with truly tiny amounts of memory that's
unlikely to really make a difference. The sample structure today is
(depending on architecture and compiler) about 100 bytes long, adding
another 40 bytes takes it to 140 bytes. ! second resolution (worst
case), 5h dive (cave diver on rebreather) results in 2,5M in sample
data.

What kind of data do these integers hold? Do they all need their own 64
bit integer? Or could they be short values? Or packed in some form?

> 2) I am reticent to start a new branch. I feel that we should rather do 
> stepwise patches to the main branch. Is this a sensible approach? This 
> probably means that we should hold off until after the release of V4.1? 
> Modules currently affected are dive.h, parse-xml and profile.

That's the whole purpose of a branch. To hold code that isn't ready to
go into master. It makes it easier to collaborate and easier to merge
for me.

> 3) About reading dive log xml files. Miika and myself are trying to 
> write xslt that does not require exslt. It appears Subsurface can easily 
> handle irregular item definitions, that is, each line defining a xml 
> sample item does not need to have exactly the same set of attributes. 

Correct. That has always been the way we did XML in Subsurface - remove
everything that's redundant.

> Currently it appears that many xml log files are written by Subsurface 
> with time, a depth, and then only attributes that indicate changes to 
> the values of these attributes. This allows the dive log only to update 
> attributes when values of parameters change, e.g. temperature or PO2. 
> But will Subsurface accept an extreme degree of unbalanced attributes? 
> The extreme case is if each xml sample item only has a time attribute 
> and one other attribute? This means that the attributes are not reported 
> regularly but only when a value, e.g. depth, presssure or PO2 has changed.


And then we have multiple samples with the same time (when more than one
thing changes)?


/D