Patches to add basic support for the Suunto EON Steel

[Linus Torvalds]

On Tue, Oct 28, 2014 at 11:42 AM, Dirk Hohndel <dirk at hohndel.org> wrote:
>
> Actually, dive mode and conservatism and battery voltage are all per dive,
> not per sample. So we don't even need DC_SAMPLE_VENDOR. This should all be
> contained in the dc_buffer_get_data(file) - so the question remains,
> what's in that buffer?

That's the raw data. It's not *useful* to subsurface, Dirk.

That would mean that we would have to just parse it all again, using
EON Steel-specific parser. That's pure and utter crap. At that point,
why the hell should we have anything to do with libdivecomputer in the
first place?

Why am I wasting time trying to get Jef to take my patches at all?

I can happily just say "screw libdivecomputer", and do a EON Steel
importer inside subsurface, the way the Uemis one does. If that's what
you want, I'll do it. It will probably make it much easier to get the
patches accepted.

But I think that kind of approach is silly. I would much rather
improve the actual libdivecomputer interfaces, and report back
strings. NOT some kind of "raw divecomputer data".

Because if you want raw divecomputer data, and then intend to parse
that again in subsurface, then seriously, all the effort I put into
making the code more acceptable to Jef was just totally wasted effort.

What I do *not* want to do is have the pain *twice*. Either we parse
it in libdivecomputer, *or* we parse it in subsurface. Not both. Not
some unholy mixture where libdivecomputer parses the basic samples,
and then subsurface parses the rest.

Just tell me. Do we do the parsing in subsurface and I throw away the
libdivecomputer patches, or do you want sane libdivecomputer
interfaces?

I'm ok with either, really. Avoiding libdivecomputer makes my life
easier. I think it would be a shame, but ..

                Linus