Re: libXO-ification - Why - and is it a symptom of deeper issues?

> I would welcome competing ideas/solutions, but someone would have to actually build them, not just

> rattle off some ideas on the mailing list.

Am I missing the point of a mailing list ?  it is a place to present and exchange ideas, ask why some things are the way they are , and get criticism. Rattling ideas is generally where it all starts. You cant realistically expect one to start a pervasive project like transactioanl databases for an OS configuration without not one mailing list discussion, but a lot of consultation. 


> There are tools available to filter json/ucl output
yes they are. vim is one . sed is another. awk is the third …  But a pipe needs both ends to talk the same language. I can generate json as output, i can filter it  , but what tool in FreeBSD will accept it as input ? None.  A

> and my forthcoming uclcmd

What uclcmd does / will do ?  

> UCL is a good solution to having a universal config file, and is better
> than the bespoke config files each utility has


I agree with you, if you manage somehow to port every ad-hoc database FreeBSD has in base to ucl, (including all the bestiary we have in /etc ) and offer tools to parse them in the rc init system to fetch the settings. I dont expect this to be done in one release , but do you tend towards this in your projects ? One config format to rule them all is good. Yet another config format in selected places in base is evil.

>  A transactional database
> might be better (for some uses, likely less so for some people), but I
> don't hear anyone volunteering to do that work.

IIRC Solaris uses sqlite. Might be a decent solution. ( a lot of the ad hoc unix databases are relational databases in disguise, with unix tools acting as operators)  And if you abstract a config interface API over UCL, someone could benefit  from it by plugging in a transactional backend one day. All you would have to do is not directly plug in UCL, but work on a orthogonal abstract API. You could even  model it after UCL API.
Please consider it. 


> I would welcome competing ideas/solutions, but someone would have to actually build them, not just

> 
> lib-izing all of the utilities instead of using libxo is a better
> solution. It would likely be gratefully accepted if someone were to do
> it, but most likely, no one will.
> 
> libxo exists now, and most applications can be converted very quickly
> (although care does need to be taken, and it sometimes has not been).
> 
> There are tools available to filter json/ucl output, namely textproc/jq
> and my forthcoming uclcmd
> 
> One of the major other consumers of the json/xml output of libxo, is web
> control panels. This is why Juniper is doing the work, and I can think
> of a list of other appliance vendors who would love to replace fragile
> per-application parsers with a json parser to extract data from various
> command line tools.
> 
> UCL is a good solution to having a universal config file, and is better
> than the bespoke config files each utility has. A transactional database
> might be better (for some uses, likely less so for some people), but I
> don't hear anyone volunteering to do that work.
> 
> So, libxo and libucl may not be the very best solutions, but they are
> the ones that are moving forward. I would welcome competing
> ideas/solutions, but someone would have to actually build them, not just
> rattle off some ideas on the mailing list.
> 
> -- 
> Allan Jude
>