Date: Sun, 15 Nov 2015 21:44:42 +0200 From: Dan Partelly <dan_partelly@rdsor.ro> To: Allan Jude <allanjude@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? Message-ID: <C9828129-DBE1-4BE9-B957-863C4B4E152E@rdsor.ro> In-Reply-To: <5648C89C.2050206@freebsd.org> References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <5648C89C.2050206@freebsd.org>
index | next in thread | previous in thread | raw e-mail
> 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 >help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C9828129-DBE1-4BE9-B957-863C4B4E152E>