"The server returned the following information"

Dirk Hohndel dirk at hohndel.org
Sat Jan 3 16:14:11 PST 2015


On Sat, Jan 03, 2015 at 04:00:44PM -0800, Linus Torvalds wrote:
> On Sat, Jan 3, 2015 at 1:38 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
> >
> > Fix will be pushed momentarily
> 
> Thanks, seems to work fine. Now it didn't complain when I updated to
> the latest version.
> 
> I think I have everything I can do for EON Steel easily done. There's
> a few things I wouldn't mind to expose, but I don't think
> libdivecomputer has the interfaces for them.

Then let's propose some interfaces may be? Or are these too specialized to
make sense?

> For example, the EON Steel has this per-cylinder, in addition to the gas mix:
> 
>  - what kind cylinder usage it is (primary/diluent)
>  - PO2
>  - transmitter ID

That seems useful and generic - and the CCR crowd will go wild :-)

> and right now I just expose the transmitter ID as a string (and not
> per cylinder - if you have multiple transmitters, you'll just get
> multiple "Transmitter ID" strings).
> 
> I think that's fine for the transmitter ID, but I'd like to expose the
> cylinder type somehow. I didn't figure out how, though.

How about you do this as strings?
"Cylinder n use", "primary"
"Cylinder n PO2", "1.6"

We can then decide if we want to add such strings as "API" and parse them
on the Subsurface side.

> There's a few more things I could add, like "conservatism" (P-2 .. P2).

That one is definitely "extra data" that you could expose as a string.

> And I just noticed that in the "state" and "notification" event mess,
> I had missed the fact that there is a separate set of "warning"
> events. So I'll send a libdicecomputer patch for that soon.
> 
> But other than that, things look good to me.

Cool.

/D


More information about the subsurface mailing list