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

[Jef Driesen]

On 04-09-14 16:23, Dirk Hohndel wrote:
> On Thu, Sep 04, 2014 at 05:34:29PM +1200, Nick Shore wrote:
>> Jef is right there, it's primarily that there are other more urgent things
>> to do. There aren't too many special cases left these days. Off the top of
>> my head, one is the surface interval - but this is an interesting one. In
>> the cases it's in the data, I read it. But in the cases it's not, I
>> generate it afterwards. Which is fine since I know the previous dives.
>> libdc might have a hard time generating it if you're only downloading the
>> latest couple of dives and had no further context to tell if a dive was
>> part of a series.
>
> And again - I wouldn't WANT libdivecomputer to calculate it. I want
> libdivecomputer to give me JUST the things that come from the dive computer.
> And nothing more. If it needs to be calculated, I can calculate it just as
> well.
>
> And no, I don't mean this in a dogmatic way. Of course libdivecomputer should
> do unit conversions and other normalizations. What I mean are things like
> fake tank pressures, surface intervalls that weren't reported by the dive
> computer, deco that wasn't reported by the dive computer, etc.
>
> I think that is exactly what libdivecomputer does today. It just is NOT
> reporting some values that the dive computer might provide... and I think we
> should add some of those :-)

Libdivecomputer will never try to calculate fake tank pressure, or any other 
sample data. That would indeed be a very stupid idea.

But what about header data, like begin/end pressure, temperature, maxdepth, 
divetime, etc? There are several devices where such information isn't available 
from the header, but where it's (indirectly) in the sample data. In that case 
libdivecomputer can calculate the missing info from the sample data. I already 
do that in a few places for divetime and maxdepth.

 From my point of view doing this provides a more consistent user-exerience for 
the application developer. If libdivecomputer already takes care of falling back 
to using the sample data, then the application can just get the value. The fact 
that one device stores it explicitly and another doesn't, would become an 
implementation detail.

Note that I'm writing this with the future in mind. I'm not going to implement 
such a fallback immediately. The priority will always be to implement it first 
for those devices that actually store it in the header (and maybe don't even 
have the sample data).

>> Another one was the name of the diver that is available on some devices. I
>> believe Jef and I have argued over that one in the past :)
>
> Yes, Uemis gives you that. Plus the suit that the user used. Plus the GPS
> coordinates and name of the dive site. The amount of weight that the diver
> carried. And a dozen others. There clearly is a point of diminishing return
> here. I will usually err on "I'd rather have it returned by libdivecomputer",
> but on some of those I certainly would agree with Jef. E.g. diver name... for
> 99% of the cases what would the consumer (the dive log software) do with that
> information? Tell the diver "these aren't your dives"?
>
>> While we're talking about accessing values, dare I ask for the serial
>> number to be a char* again.
>
> :-)

Of course you may ask ;-)

Jef