[Portland] uni-conf

[Hubert Figuiere]

On Friday 01 September 2006 14:56, George Kraft wrote:
> I don't know much about Portland, but I wanted to ask if Uni-Conf has
> been considered as a desktop neutral API for application configuration?
>
> http://open.nit.ca/wiki/?page=UniConf

Last year a DDC 2005 there was a presentation about that.

If UniConf was ever considered it would have to be forked with the whole 
WvStreams library. The persons that where pushing UniConf no longer for 
NITI[1], so I think the probability to have somebody from NITI to actually 
cooperate is thinner, given that they have no interest in the "free desktop" 
market. (prove me wrong)
UniConf heavily depends on WvStreams, so you would have to bring in most of 
the library (in C++) to use it.

UniConf represent IMHO an elegant way to manage configuration data, in a 
client/server architecture, with a simple way and a great exentsibility.
Writing a UniGen (generator) allow to implement bridging with other 
configuration systems, and that is actually how they implement the storage, 
etc.

As for API stability, that is where things gets tricky. WvStreams is a full 
fledged C++ library, and I must admit that its implement is even less 
protective than Qt or KDE when it comes to ABI compatibility. That means it 
is harder to maintain in that regard. UniConf itself can have a complete C 
API that would make binary compatibility easier, but this still does not 
address every problem that the portland project wants to avoid.

Bottom line: despite a great versatility and flexibility, I think that this 
solution present too many problem for the portland project to even be thaught 
about. Sure, nothing is unfixable, but it is actually some work. If you have 
more question, let me know. I haven't looked at WvStreams since last October.

#disclaimer: I only provide a personal opinion here

Hub

[1] this include myself