[configuration] CONFIGURATION-427 - WAS Steps towards next release

[Oliver Heger <ol...@oliver-heger.de>]

Am 17.08.2011 00:04, schrieb Emmanuel Bourg:
> Le 16/08/2011 22:27, Oliver Heger a écrit :
>
>> Aren't we free to decide how to represent data structures in a
>> configuration? I mean, the dot keys used by XMLConfiguration is also
>> just a convention. We could transform a plist file to a XML-friendly
>> structure and store it in a hierarchical configuration. We just have to
>> document how to access list structures. We could then add specialized
>> convenience methods to PListConfiguration for accessing lists in a way
>> more intuitive for plist users. Wouldn't this be an option?
>
> Our plist configurations are already hierarchical. The difference lies
> in the way the lists are stored.
>
> In the XML way a list is typically structured as:
>
> root
> list
> element -> value1
> element -> value2
> element -> value3
>
> In the plist way it's structured as:
>
> root
> list -> [value1, value2, value3]
>
>
> My understanding is that in a plist file a path can't be used more than
> once. So if you explode the structure of a list to put one element per
> node, you have to reverse the operation and regroup sibling nodes into a
> list when the configuration is written. Headache guaranteed for the
> implementer :)
>
Yes, it would certainly mean more effort on implementation side, but it 
would also gain some benefits for users. We do transformations for other 
configuration implementations, too, e.g. in 
HierarchicalINIConfiguration. Well, the transformation for plist 
configurations seems to be more complex.

That said, I am not against the patch. If you think it works for most of 
the users, just go ahead and commit it. Alternatively we could postpone 
this issue to the next release, so there is more time to think about a 
solution. I am still on the opinion that it makes sense to get out a 
binary compatible release soon which has been updated for Java 1.5. Here 
the fix could be included.

Oliver

>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org