[PATCH] Added support for parsing temperature in the dive header

[Linus Torvalds]

On Fri, Sep 5, 2014 at 2:58 PM, Jef Driesen <jefdriesen at 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.

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.

              Linus