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>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.=20 > There are tools available to filter json/ucl output yes they are. vim is one . sed is another. awk is the third =E2=80=A6 = 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 ? =20 > 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.=20 > I would welcome competing ideas/solutions, but someone would have to = actually build them, not just >=20 > 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. >=20 > libxo exists now, and most applications can be converted very quickly > (although care does need to be taken, and it sometimes has not been). >=20 > There are tools available to filter json/ucl output, namely = textproc/jq > and my forthcoming uclcmd >=20 > 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. >=20 > 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. >=20 > 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. >=20 > --=20 > Allan Jude >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C9828129-DBE1-4BE9-B957-863C4B4E152E>