RFC: support for deco algorith and parameter fields

[Linus Torvalds]

On Fri, Oct 17, 2014 at 1:25 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
>
> 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?

Btw, strings is what the EON Steel returns natively. So it will ave things like

  DeviceLog.Device.Name: "EON Steel"
  DeviceLog.Device.SerialNumber: "#p1437019"
  DeviceLog.Device.Info.SW: 1.0.3
  DeviceLog.Device.Info.HW: "71.2.0"
  DeviceLog.Device.Info.BatteryAtStart: "Charge: 73%, Voltage: 3.959V"
  DeviceLog.Header.Diving.Algorithm: "Suunto Fused RGBM"
  DeviceLog.Header.Diving.Gases.Gas.TransmitterID: "1437137031"

that are fundamentally strings (they are returned as utf8, even the
ones that are mostly numerical).

(Also, interestingly, it saves the firmware version per dive: that
"1.0.3" version is the pre-release one we were diving with, but I have
since updated the device to the final 1.0.7 firmware, but the dives
are reported with the firmware-at-the-time)

I would really prefer to see libdivecomputer use more plain *strings*.
We talked about this long long ago about the serial number too: trying
to encode things as numbers is fragile as hell, and it's also very
complicated because you need to specify (and often over-specify) all
the details. A string, in contrast, doesn't need much specification at
all, and allows for obvious extensions (ie maybe the device is doing
something that is very similar to Bühlmann, but has some vendor
extensions - a string can just *say* so, while some crazy enumeration
model will inevitably either be overly complicated, or won't be able
to express the fact that it's not just Bühlmann, it's some vendor
variation there-of).

Strings are good. The UNIX people taught people that long long ago.
Back in the early sixties, it was ASCII. These days it's utf8, but
aside from that minor change, the basic rule has remained the same.
Freeform text really is very very powerful.

This is *especially* true for random data that is really
informational, and not to be "plotted". Yes, you might want to plot
the deco data, but if we plot that in subsurface, it will be with
*our* algorithms (currently just Bühlmann 16 with gf, maybe that will
change in the future), and at best that will be just something that we
can try to match against whatever the divecomputer vendor claimed they
did.

          Linus