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

[Jef Driesen]

On 2014-08-25 18:06, Dirk Hohndel wrote:
> Humor aside, I continue to be puzzled by this argument. There are a 
> couple
> of divecomputers that provide these data and there is a clear use case.
> Whether you use it on your dive computer frankly doesn't matter (and 
> just
> for the record, I tend to always adjust the tank size on my Uemis). 
> What
> matters is that there are data that could reasonably be provided by
> libdivecomputer at zero incremental cost for all the dive computers 
> that
> don't have it, though for the past two years whenever the conversation
> comes up you explain why it's not needed.
> 
> I agree, gasoline cars work and most cars have a gasoline engine. There
> are only a few electric car makers out there. Yet as the owner of two 
> such
> cars I think it would be useful if gas stations and hotels provided a 
> way
> to charge cars. Oh, and they use different charging ports. One that's a
> bit awkward but very popular, the other that's better and used by the 
> rest
> of the world. Smart gas stations and hotels will support both...
> 
> But I digress. It's your project. I continue to be too lazy to fork it 
> so
> I will continue to just work around the parts where you don't see that 
> you
> continue to go the wrong direction.

[Sorry for the slow response, but I've been busy with non 
libdivecomputer related things.]

I was only explaining the arguments why *I* think the tank size isn't a 
critical piece of information. Just like you explained yours. Nothing 
more, nothing less. With good arguments, you can certainly convince me 
to do things different. That's why I asked for feedback in the first 
place! Otherwise I would just have applied the change and be done with 
it.

Yes, you are absolutely right that I'm often reluctant when it comes to 
adding new features. However you have to keep in mind that I get many 
request for adding new features. Usually those are along the lines of 
"Hey, I have dive computer X and the official application shows info Y, 
and I would like to have that in application Z too". In theory (ignoring 
the time required to reverse engineer the necessary info), I can easily 
add support for such new features, because they don't really interfere 
with anything else. But the real question here is not whether we can 
support this, but whether we want to!

Remember that adding features ad-hoc, based on what a certain 
manufacturer (e.g. suunto, which happens to be the first supported 
devices) provides is pretty much how the current libdivecomputer 
"design" evolved into what we have now. Linus and you already complained 
several times about the current libdivecomputer api. Don't get me wrong, 
I absolutely agree that many of those concerns are indeed valid and 
should be addressed. But for the time being, I just don't want to repeat 
those mistakes again. So yes, I'm a lot more careful when it comes to 
adding new features now.

Also from an application point of view, I think it's more interesting to 
have a rather limited set of features that is very well supported by the 
majority of the backends, then having a large number of features that 
are only supported by a few backends. That's basically why I have been 
spending most of my time and energy on improving the existing features, 
and not adding anything new.


But okay, maybe I went into the defensive corner too fast. So let's 
start all over again, and assume we want to include the tank size too. 
Can you explain me how you would use the dc_tankdata_t structure in the 
following scenarios:

  * No tank size available (e.g. just begin/end pressure): How do we 
indicate that the tank size isn't available?

  * Metric vs imperial tanks (e.g. water vs air capacity): How do we 
indicate the difference? For imperial tanks, we'll certainly need the 
working pressure. Metric tank also have a working pressure, and although 
it's not needed for calculating the amount of gas, it may be available 
too. Do we convert imperial units to metric units to be consistent with 
the rest of the libdivecomputer api, or do we make an exception here?

And then we can work out something from there.

Jef