Date: Sun, 15 Nov 2015 13:02:04 -0500 From: Allan Jude <allanjude@freebsd.org> To: freebsd-current@freebsd.org Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? Message-ID: <5648C89C.2050206@freebsd.org> In-Reply-To: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kk1cvSuaCKkPaDmsUvoFduAcNtcJtCPjl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2015-11-15 07:54, Dan Partelly wrote: >=20 > Hi all, >=20 > I was looking at the new facility of dumping JSON,XML from many utils i= n base and after some funny minutes, I couldn't stop ask myself =E2=80=9C= Ok, this is funny , but why ? =E2=80=9C And I couldn't find a real answe= r. Ill outline what I think: >=20 >=20 > 1. Undoubtedly, it makes base code slightly harder to understand and ma= intain.=20 > 2. I have seen the idea that this makes the information dumped by utili= ties in the base easily accessible programatically. OK, maybe it does , b= ut > it doesn't fit with the current paradigm of "tool | filter | tool=E2=80= =9D at all. There are no tools able to accept JSON and filter it in any m= eaningful way, and I > dont see too many ppl changing their code to read JSON instead of text.= I don't even see the base tools changing. This output may be useful in = corner cases only. > 3. The integration of libxo IMO only points at a much deeper issue IMO.= It is only an expression of the need of a mechanism aimed at binary code= reuse. But it does not solve the problem, it only adds yet another possi= bility in a world where too much choices already result in too much split= s and incompatible APIs.=20 > 4. This whole effort would have been IMO much better served by porting= the bulk of ifconfig(8) , route(8) and wpaclient(8) to a library API, mu= ch like the libs for geom, zfs , etc , ready for reuse of 3rd party code.= Eventually writing network control daemons in time over it , much like s= olaris does. >=20 > 5. A port of partial OS config data to UCL =E2=80=A6. would induce yet = induce another orthogonality violation. What makes UCL better than the be= stiary of ad hoc databases already existing in BSDs ? Programatic readabi= lity, yes. but it does not add any real much needed functionality such as= *transactional databases* for system tools. Why not research a proper = solution - easily accessible by other programs ,orthogonal , transactiona= l, and ACL protected solution which can be used all over the place , f= rom OS boot, to ABI management, service management, network management, u= ser management. I hope this day will come, a day when I will not have to= edit a single config file manually, yet I would have access to all the c= onfig and system state easy with wrapper APIs. In the light of this poin= t, why go with UCL ? It is not orthogonal, it is not transnational, and e= diting the config files directly would result in the same old human error= s which bite as all from time to time. >=20 > 5. It is my opinion that Solaris addressed some of those issue. Solaris= FMRI and SMF are lightyears ahead of the very tired models we keep using= on BSDs. Why not build on the insight offered by those (or even on the i= nsight offered by Windows :P) , then inventing more adhoc solutions and a= d-hoc databases, which do not address the real issues we have , like bina= ry code reuse, service management issues, lack of a system wide publishe= d -subscriber bus ( not kdbus :P ) fault detection and reaction, fault re= porting, all much needed parts of a modern OS.=20 >=20 > And now thee questions >=20 > 1. Why lib XO ? Why burden the OS for some corner cases where it may be= useful ? >=20 > 2. Was there any real talk on how to bring FreeBSD up to speed regardin= g those issues ? A period of research on what exists, on what can be don= e , and ensure important things are not showed in background and replaced= with yet another ad-hoc config database which lacks modern features ? > From where I am standing, this could be a project spawning multiple yea= rs , but it would be well worth it, and in my opinion it would be also wo= rthy of=20 > the freeSBD foundation sponsorship for several years in a row. The feat= ures I touched upon became very important parts of oder OSes, and rightly= so.=20 >=20 > Note: >=20 > this message is serious and it is not intended to start flame wars, rel= igious crusades, or offend anyone.=20 > =20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=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. 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. --=20 Allan Jude --kk1cvSuaCKkPaDmsUvoFduAcNtcJtCPjl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJWSMilAAoJEBmVNT4SmAt+lfoQAI2aZ0HU8EWL/ReP+dHDBYnF GOxZ3ZGllfMes0J+cDFklI3QVe6cC7juPB0x6jfkEQwV427KF0LyiglR8ZGqwHUJ L5h+c1y8+QAeMqtIbQfdABMj1s6kD4FaWakXJM5Uxbo2fIy1aZRYiX6IwT13+k2e 42pkUYDCvRS4Uyr8upr4kgSnLWx6ZkazQ0/xlrnZvv68BB1PlVUQgATyUEuCA16Z dT/2OqwENwH9yExHrZVmsUVq1FCbuK8sQebJT45Y92uVjbgdqBWVuFclRIze0Gze XFVfOTqDOVZGhLMWrPvnO4IJuml+YnZCFKh5qjGBX5joZD5v7ileS0bfwfZtsnoE xecii47hWdQu9nsS3x/ICu0ND9ewnLJekZthSntmSrFk71b64T3o0Yq9ucushM1p dUfh2PJiJM4U76vx0xNEy5S48iL7ge0NoBQff7Nbbl3GuXL2Eop8BDLVyu6ixPFQ eBg42//zm3zdOUXZ3ULhpZL7itSg9r6ubyFr7RDIrOpxpcYvEbM6MUDf/98bipKf Zxs1/nuxzCueCuj9yNDpr+/4CaQJn9KeluHjYAZIWxjIE1f55GU3OnqdUhqmYYwL oByizvCtq1JKxBa6p3ifAWWpz84irvfdymi9eEZYAomw0VkVViNUJFA6UafbQS3C GabbMeyi1uWGefLncudW =oIMJ -----END PGP SIGNATURE----- --kk1cvSuaCKkPaDmsUvoFduAcNtcJtCPjl--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5648C89C.2050206>