On 06-09-14 20:46, Linus Torvalds wrote:
On Fri, Sep 5, 2014 at 2:58 PM, Jef Driesen jefdriesen@telenet.be wrote:
I can mind of see the point of doing max depth and time, just to always have those fields in the header data for a dive.
But cylinder pressures etc? Bad idea. They aren't always there anyway, claiming them just because you also have sample data is just wrong, stupid, and print to error (ie the cylinder connected to the pressure sensor may not be the first one, you don't know, stop gues
How can you not have begin/end tank pressure, when the samples contain tank pressure values?
You may not *have* sample pressures, because maybe you don't have a transmitter.
Well, if there is no sample pressure, then of course libdivecomputer will never make up such data. That's just stupid.
For the tank pressure (and other fields) there are 4 different cases:
1. No header, no samples: This is probably a non-air integrated model. We won't try to provide any pressure data whatsoever.
2. Header, but no samples: This is typically an older or lower-end air-integrated model, which doesn't have enough memory to store a full pressure profile. We provide just the begin/end pressure from the header. We won't try to interpolate sample data.
3. Samples and header: This is a device that gives us everything. Nice and easy.
4. Samples, but no header: This is basically a special case of the previous one, except that the device tries to save some memory by not storing redundant information. The begin/end pressure can easily be obtained from the sample data. This is the category where this discussion is all about.
The point I'm making is that the user of libdivecomputer cannot possibly _depend_ on having beginning/ending cylinder pressure data.
So there is no point in trying to make such data up. It doesn't buy the library user anything, and you almost certainly make things *worse*, not better.
In other words: you add no actual information, you add nothing that is valuable, but you *do* add confusion.
If the pressure data is in the samples, then subsurface (or any other user) can - and will - look at the sample data. If you start reporting beginning and ending pressures separately that you just take from the sample data anyway, the *only* thing you do is to make for a more complex download with more room for errors.
Why the f*ck would you want to do that? It's stupid. It's wrong. It doesn't _help_. It only hurts.
Now, if the dive computer *separately* reports data like that, in addition to the data in the samples, then by all means, pass that kind of information through. But don't make it up based on other data.
An example of that is "maxdepth", where many dive computers (all?) report maxdepth as a separate thing from the depth data in the profiles. And it doesn't always match - the dive computer may save sample data at some particular frequency that is almost certainly separate from the actual internal sampling frequency. So in this case, maxdepth may actually have a *separate* value from the maximum depth found in the samples. THEN it is real data.
But if it's just something you figured out from the samples, you SHOULD NOT LIE to the application and tell it that the dive computer reported it.
Get it? You'd be *lying* about the dive computer. You'd be making shit up. And you'd almost certainly be *worse* at it, than we are. You only look at one dive computer at a time, subsurface will not. You don't have any way to match pressure sensors to particular cylinders, but subsurface might (ok, we don't, but at least we track it and there's a chance we might allow user editing etc). The moment you say "let me make things up based on other things", you're basically just making it harder to use the library sanely, because at that point we can no longer trust the data you give us to be what the dive computer reports. See?
I'd much rather *not* get begin/end pressure data, and know that that means "the dice computer does not save that separately" than get made-up pressure data that I then don't know if it's the dive computer that has such things, or just Jef that is making shit up again. See the difference between the two cases?
(And this is not just about pressure data. This is about temperature, about depth, about anything. Give us what the dive computer reports, not some "sanitized view" that means that we don't know what is dive computer and what is some random library version.
I think the main reason why we have a different opinion here, is because we see the role of libdivecomputer a bit different. You prefer a "minimal" library that just provides access to the data that is explicitly stored by the dive computer. So libdivecomputer only abstracts away where (byte offset) and how (little/big endian, metric/imperial, etc) the data is stored and that's it. That used to be my opinion too, but nowadays I think that ideally (and we're talking about the long term goal here) it should go one step further: libdivecomputer gives you an abstract representation of a dive, and the application can just get the info, no matter where or how it is stored (explicitly in the header or implicitly in the samples).
From my point of view, the main benefit is that the application side becomes more simple. Instead of requiring all applications to implement their own fallback code, it would all be centralized in libdivecomputer. Then libdivecomputer could guarantee things like if the device has a pressure sensor, then you can just get the begin/end pressure. If there is a full pressure profile, then great, you can get that too, but that's optional. (Again, this is for the long term goals.)
You consider this as making things up or lying, I don't. For things like begin/end pressure, maximum depth there is no real calculation involved. It's basically collecting some trivial "statistics" on the sample data. How would an application be able to calculate this different or better? The input data is exactly the same! Yes, you are right that if a user has multiple dive computers, then the application may have a bit more info. But in that case, you'll have to merge the data somehow anyway. The maxdepth (or other header data) from two devices will rarely be exactly the same, and that's true regardless of whether you take maxdepth from the samples or dive header.
I'll try to illustrate my point with a complete different piece of date: the gas mixes. Most dive computers store the available gas mixes in the header. But there are several exceptions to this rule. The ostc has an extra manual gas that can be changed during the dive. The nitekq has no gas mixes in the header at all, only gas switches in the sample data. What should libdivecomputer return when subsurface (or another application) calls dc_parser_get_field with the DC_FIELD_GASMIX? Just the gasmixes in the header? For the ostc or nitekq that means you would miss some or all the gas mixes. Or should we parse the sample data and also pick up the manual gas (ostc) or process the gas switches (nitekq)? Do you also consider this making things up or lying?
If you ask me, libdivecomputer should do the latter, because this is just some internal detail of how the device records the gas mix data. The end user or the application shouldn't need to be aware of such things. I just don't understand why this would be any different than collecting begin/end pressure or maxdepth from the sample data. Where do you draw the line?
[To give a bit more context on why I picked the gas mixes as an example. It has been discussed several times already that the current libdivecomputer api for gas switches is far from ideal. A much better design would be to provide the id of the current gas instead of the O2/He percentages directly. That would for example solve the problem that right now you don't really know which mix you switched to, if you happen to have configured two identical gas mixes. But that means libdivecomputer has to collect all gas mixes up front, to be able to assign an id!]
I'm also not convinced that the application can always calculate missing data better than libdivecomputer can, as you claim. Libdivecomputer can easily apply device specific knowledge, which is much harder (or at least annoying) to do on the application side. Take for example the sensusultra. It records no divetime (or maxdepth, etc) in the header, only depth and temperature samples. But it also has a user configurable depth threshold and endcount setting to determine when a dive is considered over. (I assume all dive computers use a similar logic, but with the settings hardcoded.) The consequence is that the tail of the dive always consists of endcount samples with a depth shallower than the threshold. Most users will likely prefer this tail to be excluded from the divetime. Libdivecomputer can easily take these settings into account (although today it doesn't do that yet). Do you really want such device specific knowledge on the application side?
Note that I agree that for certain fields, like divetime, there are indeed multiple ways to calculate it. But as I already explained in my previous email, there is not really a correct answer, and if the goal is to have a consistent value across different devices then you should probably always ignore the value from the header and calculate it from the samples.
Jef