[PATCH] Added support for parsing temperature in the dive header

[Jef Driesen]

On 04-09-14 16:30, Dirk Hohndel wrote:
> On Thu, Sep 04, 2014 at 07:21:19AM +0200, Jef Driesen wrote:
>> On 25-08-14 00:02, Jef Driesen wrote:
>>> For the api, maybe we can stick to the DC_FIELD_TEMPERATURE with a single double
>>> value, but use the flag parameter of the dc_parser_get_field function to specify
>>> the subtype:
>>>
>>> typedef enum dc_temperature_t {
>>>      DC_TEMPERATURE_SURFACE,
>>>      DC_TEMPERATURE_MINIMUM,
>>>      DC_TEMPERATURE_MAXIMUM,
>>> } dc_temperature_t;
>>>
>>> In the application you would call like this:
>>>
>>> dc_parser_get_field (parser, DC_FIELD_TEMPERATURE, DC_TEMPERATURE_XXX, &value);
>>>
>>> What do you think?
>>
>> Answering my own question, I think it will be easier (to implement on my
>> side) to just define three temperature fields:
>>
>> DC_FIELD_TEMPERATURE_SURFACE
>> DC_FIELD_TEMPERATURE_MINIMUM
>> DC_FIELD_TEMPERATURE_MAXIMUM
>>
>> instead of subtypes. On the application side this shouldn't make any difference.
>
> The difference is, I think, that THIS change requires the app to be aware
> of this and read all the values. The alternative change would an older app
> to just work (and simply not know which type of temperature this is - just
> like before).
>
>  From a Subsurface case I am happy with either solution.

The DC_FIELD_TEMPERATURE field doesn't exist yet, so there is no backwards 
compatibility problem here. An application that doesn't care about the type of 
temperature, and which just wants a temperature, will also have to pass some 
subtype in the other solution. I would just pass 0, then it would get the 
temperature corresponding to the subtype we happen to list first in the enum 
(SURFACE for example). That wouldn't be any different than passing 
DC_FIELD_TEMPERATURE_SURFACE without subtypes. Or am I missing something?

Jef