libXO-ification - Why - and is it a symptom of deeper issues?
Dan Partelly
dan_partelly at rdsor.ro
Sun Nov 15 19:44:44 UTC 2015
> 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
>
More information about the freebsd-current
mailing list