On Tue, Oct 28, 2014 at 11:58 AM, Linus Torvalds torvalds@linux-foundation.org wrote:
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.
.. btw, not just that, but it will make some of the interfaces simpler too if I can just fill in the data directly into our divecomputer structure. So I certainly don't object to changing my importer to be more Uemis-like. No callbacks, no impedance matching, no need to try to make things compile in an odd environment etc.
I still think it would be *much* better if we fed the thing back to libdivecomputer. Not because I particularly care about the other projects that use it, but just because it's the right thing to do.
But I really think it's wrong to parse the data twice. So if we want battery information, I'm not going to be part of anything that says "here's the raw vendor information, you parse it again yourself". That just makes me throw up in my mouth a little. I'd make it return the data as a string. And NOT using DC_SAMPLE_VENDOR, but as something that is *defined* to pass up a string, so that it isn't some one-off random hack.
Linus