On Tue, Oct 28, 2014 at 11:42 AM, Dirk Hohndel dirk@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