RFC: support for deco algorith and parameter fields

[Dirk Hohndel]

On Fri, Oct 17, 2014 at 10:15:07AM +0200, Jef Driesen wrote:
> 
> >- DC_DECO_ALG_UNKNOWN if it does deco calculation, but we don't know the
> >  algoright
> >- DC_STATUS_UNSUPPORTED means the backend doesn't have this function
> >  implemented
> 
> The DC_STATUS_UNSUPPORTED is used in case a feature is not supported by the
> dive computer, or not implemented by the backend. The line between those two
> is very thin. If it's not implemented by the backend, that could be due to
> the fact that it's not supported by the dive computer, or because we don't
> know yet where and how it's stored. But usually we don't know that
> difference in advance.
> 
> The same logic applies here. Of course every dive computer will use some
> deco model (unless in gauge/freedive mode), but for libdivecomputer
> unsupported and unknown are basically the same thing.

I won't push too hard on this one. I disagree with you, but that doesn't
mean that I'm right.

Now, Linus is sitting next to me on the lounge (we're connecting in
Atlanta on our way home... don't ask) and came up with an embarrassingly
simple solution to all this. And I hate to say it, but I think he's right.

Given that every vendor messes with their implementation, invents their
own secret sauce and no one really really correctly implements the (often
not well defined) algorithms... how about we just return a string?

On the OSTC one could return "Bühlmann ZHL-16c GF 30/70 sat 110 desat 90"
On the Aeris one cour do "Bühlmann ZH (params unknown)"
etc

This avoids the complication with the parameters and basically allows us
to give back what we know, without having to try to invent too much
structure around it.

What do you think?

/D