From owner-freebsd-current@freebsd.org Sun Nov 15 19:44:44 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1C1CBA30D58 for ; Sun, 15 Nov 2015 19:44:44 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id A1A831114; Sun, 15 Nov 2015 19:44:43 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from [192.168.1.100] (unknown [79.119.24.18]) by mail.rdsor.ro (Postfix) with ESMTP id 3E2A312102; Sun, 15 Nov 2015 21:44:42 +0200 (EET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? From: Dan Partelly In-Reply-To: <5648C89C.2050206@freebsd.org> Date: Sun, 15 Nov 2015 21:44:42 +0200 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <5648C89C.2050206@freebsd.org> To: Allan Jude X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 19:44:44 -0000 > 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