[PATCH] Try to sanely download multiple concurrent cylinder pressures

[Linus Torvalds]

On Tue, Jul 25, 2017 at 12:13 PM, Linus Torvalds
<torvalds at linux-foundation.org> wrote:
>
> I'll fix that, since I can easily generate bogus data with many sensors.

Actually, the first thing I need to fix is the save format.

Right now our pressure data looks like this in our XML files:

    pressure='180.84 bar' sensor='1'

and that is actually horrible for various reasons. Once you have
multiple sensors, that "sensor='N'" format ends up being really
unhappy, not least because of XML rules (but also because we need to
associate the sensor with one of the pressure values, and so it's
fundamentally a bit ambiguous, especially as we currently skip the
sensor data if it matches the previous one).

To continue on the horrid format, if we have a second pressure, right
now we can only do that for one *fixed* sensor per dive, which is
fixed to the Oxygen bottle, and then we add a field like

    o2pressure='171.76 bar'

to the sample XML.

The git format is very similar, although with slightly less
unnecessary syntax crap (ie it would be just

    180.84bar sensor=1

and

   o2pressure=171.76bar

respectively).

Now, for legacy reasons (so that you can continue to use old clients
on the cloud data, for example), I propose to just continue to use the
old format for the cases where it works.

But for dives that actually have multiple sensors and aren't of that
"CCR with O2 sensor" form we need to have a new format, simply because
the existing format can't handle it.

My current personal preference is to not use the "o2pressure=" or
"sensor=" tags at all, but instead just indicate the sensor as a ":N"
after the unit (bar).

So we'd just have something like

    pressure='180.84 bar:1'

and

    pressure='171.76 bar:2'

to indicate the pressures of sensor 1 and 2 respectively (and it
wouldn't matter if it's a CCR dive and one of the sensors is connected
to an Oxygen bottle or not - it still uses the same format).

Comments? Do people hate this? Any other suggestions?

Note: regardless, we *will* have to support that mixed old-and-new
format for a while, so it's going to be a bit hacky and ugly for some
time regardless of what syntax we'd choose.

*Eventually* we can maybe decide to only save in the new format,
because in a year or so maybe we can just say "everybody has the new
clients, we can just use the simpler new save format unconditionally".
But I'll have to write the code to fall back to the odd special-cases
for now when possible.

I guess not a lot of people actually look at the raw git tree or the
XML, so I doubt people have strong opinions on the format. But if you
do have a strong opinion, speak now or forever hold your peace..

                Linus