Next round of api improvements.

[Jef Driesen]

On 2012-11-16 20:58, Artur Wroblewski wrote:
> On Fri, Nov 16, 2012 at 6:40 PM, Jef Driesen <jefdriesen at telenet.be> 
> wrote:
>> On 2012-11-15 19:43, Dirk Hohndel wrote:
>>> Please make the memory application owned and have the application 
>>> be
>>> responsible for freeing memory. Unless you are planning to run
>>> libdivecomputer on a wristwatch the overhead for that is negligible
>>> with
>>> today's OSs (that all have a reasonably smart malloc implementation
>>> that
>>> will reuse the recently freed memory block on its own).
>>
>> I certainly agree that this is probably the most intuitive and 
>> simple
>> design.
>>
>> But while I'm not too concerned about the memory allocations by
>> themselves, I still find it a bit silly having to allocate resources
>> where it's not strictly necessary. For the sample data I simply 
>> can't
>> think of any use-case where you would want to hold on to the sample
>> objects outside the callback function. Hence my search for possible
>> alternatives.
>
> I agree with Dirk. Trust the users of your lib and keep it simple.
>
> Create an instance of data for each sample or have one data container
> and require application to copy the data before next iteration step.
>
> There are plenty of data containers and frameworks (i.e. language 
> bindings),
> which can be used. The simpler libdc is, the easier integration is
> going to be.
> No need to reinvent your own.

See my response to Dirk. Using "applications owns" everywhere to make 
the api consistent is fine for me.

>> CNS/OTU can be calculated from the samples
>
> IMHO, you can't if you don't have previous dive information as you 
> don't
> know the initial CNS.

True, but nobody says that an application can't take into account a 
series of dives :-)

But that doesn't mean we won't support it. We are just trying to see 
what is out there, what users want to have, and then make a good 
decision based on that.

>> , but we can consider to
>> support it too. I have no idea which devices record this in the 
>> data. I
>> know the Suunto's have this weird OLF (Oxygen Limit Factor) value, 
>> which
>> is either the CNS or OTU, whichever is higher. And I think the 
>> Oceanics
>> have a scale from 1 to 5 or something. So that might be a bit more
>> difficult to support in a uniform way.
>
> If some devices do something their own way, i.e. OLF or 1-5 scale, 
> then
> ignore it until they document how to recalculate into CNS. For those 
> who
> really want to deal with such "inventions", there sill is raw data. 
> The rest
> of us will benefit from simpler (but still flexible) interface.

That's also how I think about it.

>> I assume with NDL, you mean the remaining no-deco time? I don't 
>> think
>> any device does support that.
>
> OSTC supports above.

And we'll support it to. It's already implemented and will be committed 
soon :-)

Jef