Next round of api improvements.

[Artur Wroblewski]

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.

[...]
> 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.

[...]
> , 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.

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

OSTC supports above.

[...]

Best regards,

w