On Tue, Oct 28, 2014 at 01:02:07PM -0700, Linus Torvalds wrote:
On Tue, Oct 28, 2014 at 12:44 PM, Dirk Hohndel dirk@hohndel.org wrote:
Is this per sample data or per dive date? So I think this is a DC_FIELD_STRING in libdivecomputer nomenclature.
DC_FIELD_STRING would work, yes.
I think it would likely be but be slightly annoying as the DC_FIELD_xyz model is driven by the application, so now the application has to query these strings, which in turn means that you have to either count them up-front, or use the index model (and perhaps iterate until you get NULL's back or an error code?).
Ah. Hadn't thought of that. Having DC_FIELD_STRING return an array of pairs of strings sounds challenging. Maybe "keep calling it until it returns two empty strings" is a reasonable way of doing this. I like this better than having to first get a number of strings.
The DC_SAMPLE_xys model is nice for the kinds of things where the divecomputer just gives a random number of entries, because that's obviously how the samples work too.
Yes. Maybe it's just my mindset that's too inflexible here. I think of DC_SAMPLE things as stuff that happens "during the dive". And I think of DC_FIELD things as stuff about the whole dive. Maybe I need to drop that categorization.
Jef - would either of these work for you?
I guess I could even convert the serial number etc to be those kinds of things, and use this instead of the DC_FIELD_DEVINFO thing I wrote.
It would certainly make things nicely consistent. Let's see what Jef thinks of this direction.
/D