commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph.R...@dlr.de
Subject Re: [configuration] XmlConfiguration
Date Wed, 11 Dec 2002 15:31:11 GMT
Dito, Ola. I also don't think it can be possible to find a sensible
denominator for configuration. I see several types of usage patterns:

1) Simple properties style (some create hierachies using the dotted strings)
2) [INI] style adding the notion of groups (and better mechanisms for constructed hierarchies)
3) Full featured XML (which is harder to read and edit, but can be programatically syntax
checked DTD, Schemas)
4) XML defining Objects (like the Java Serialization, Digester/Betwixt, Castor, Koala XML,
etc.).

Each of these the come in different styles (capitalization, XML element names, etc.).

In my case, I used #4 with the notion of loading on demand and allowing reuse.

So we will have to live with *many* configuration implementations.

All that commons can do is to present clean examples of some of the above,
which then can be resued by other projects.

Cheers,
Christoph

Ola Berg wrote:
>>10 other projects also have their implementation and they don't want to 
>>switch :-((((
>>
>>it definitly doesn't make sense to have 10 implemetations for something 
>>like reading an xml config file!!!
>>is it really impossible to find a solution which can be used by all 
>>projects??
>>
>>let's join forces to find a way to have one configuration package!!!
> 
> 
> Hint (if you think it is worth it):
> 
> 1) Check out the 10 implementations, factor out a common denominator API.
> 
> 2) Merge all features from all implementations so that your thing will be the most featuresque
of them all (so that the potential "customers" won't lose anything in the transition), and
thus expanding the API from 1) above.
> 
> 3) Sell it to them by offering replacement classes that adapts your thing to theirs (a
slip-in-replacement).
> 
> 4) Offer the added functionality on their email lists, pushing the benefits of your thing.
> 
> 
> Why I don't think that the above will work is that 
> 
> a) the installed base is too big, 
> 
> b) configuration is such a core feature of your product so that you want to retain full
release/bugfix/management control over the configuration component
> 
> and
> 
> c) The different APIs take different approaches, esp when in the configuration process,
and how, the provided String values get converted into real objects.
> 
> I welcome better config utilities (even though I know that the existing impls are good
enough for about any case), but I think that when doing such a thing, considering your answer
to point c) is of great importance.
> 
> I have limited coding possibilities as of now, but I am with you in thinking (feature
requests, modelling, opinions etc).
> 
> I prefer seeing XML config files as a special case of XMLalizing object/bean structures.
> 
> /O
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> 
> 

-- 
:) Christoph Reck


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


Mime
View raw message