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

[Dirk Hohndel]

On Thu, Sep 04, 2014 at 05:34:29PM +1200, Nick Shore wrote:
> 
> On 04/09/2014, at 17:14, Jef Driesen <jef at libdivecomputer.org> wrote:
> 
> > Almost right. The original reason is a bit different. Macdive is a few years older than subsurface, and started around the same time as libdivecomputer itself. At that time the libdivecomputer parser was pretty much non-existing or at least even more basic than it is now (e.g. sample data only). So writing a custom parser was basically the only option. Nowadays the libdivecomputer has much improved (although their is certainly room for improvement!) and while Nick and I discussed switching to the libdivecomputer parsers more than once, that just didn't happen yet. It works, and there have been always some more urgent things on the todo list :-)
> 
> 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 :-)

> 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.

:-)

> >> - MacDive, just like Subsurface, would prefer to get such data from
> >>   libdivecomputer, as long as it is easy to tell if the data is available
> >>   or not - so no made up, interpolated or otherwise fabricated data.
> >>   Either an indication "the data aren't available", or actual data from
> >>   the dive computer.
> > 
> > It's hard to disagree with that!
> 
> Yep.

Hey, I found something we can all agree on.

/me celebrates.

/D