Date: Mon, 9 Dec 2013 18:17:01 +0000 From: "Teske, Devin" <Devin.Teske@fisglobal.com> To: George Mitchell <george+freebsd@m5p.com> Cc: Devin Teske <dteske@freebsd.org>, "freebsd-stable@freebsd.org Stable" <freebsd-stable@freebsd.org>, "Teske, Devin" <Devin.Teske@fisglobal.com> Subject: Re: BIND segway -> python -> first-class ports -> parsing Message-ID: <4EE82B0A-44A1-4B0E-94F0-C101625108AC@fisglobal.com> In-Reply-To: <F7052902-C640-4AAB-92D5-6A15C6C0A5EE@fisglobal.com> References: <mailman.313.1386119137.1390.freebsd-stable@freebsd.org> <529E8C53.6020208@freebsd.org> <Pine.GSO.4.64.1312032238220.15897@sea.ntplx.net> <20131204060246.GV2951@home.opsec.eu> <CAN6yY1udd1GbQVK4YR-yxNe7vqX3S1refQwch2cafRnMv=W4mA@mail.gmail.com> <CAFHbX1K1AgZ4FaEjP_vvnfiwDWsj6M3ysEVn4taX_4_p%2B1Z8Nw@mail.gmail.com> <CAN6yY1tjS=uk1Qr-sBN0PT73xpP%2BBxL8wLt9aosYfWf751rC5A@mail.gmail.com> <52A12843.3010204@freebsd.org> <0BFC927B-D72E-4926-BB3D-2C000F310BDD@fisglobal.com> <7271C4C4-7BAB-4DA7-9E10-49D5B2DB8964@mu.org> <52A51438.4090200@bluerosetech.com> <8D54491D-5A1C-4D30-AD48-12336D0726DC@gsoft.com.au> <5C28ECE3-CE0C-44A9-A7CD-08A01C714594@fisglobal.com> <52A5A7D4.4080404@m5p.com> <F7052902-C640-4AAB-92D5-6A15C6C0A5EE@fisglobal.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 9, 2013, at 9:27 AM, Teske, Devin wrote: >=20 > On Dec 9, 2013, at 3:21 AM, George Mitchell wrote: >=20 >> On 12/09/13 00:39, Teske, Devin wrote: >>> [...] >>> But keep in mind... >>>=20 >>> The real power is not in shell, the real power is in POSIX. I have the = supreme >>> pleasure of having developed C programs that can compile on: >>>=20 >>> + Windows using MinGW >>> + Mac OS X using ... gcc >>> + Mac OS Classic using SIOUX >>> NB: Simple Input/Output User eXchange >>> + Linux, Unix, BSD, AIX, OSF1, Amiga, etc. >>>=20 >>> All with a single source package. It's the power of POSIX. >>>=20 >>> So whenever I've made a choice to target "/bin/sh" as a platform, it's >>> always *only* ever been based on the decision of "reach". >>>=20 >>> Shell quite often doesn't cut it. Prior to shell, I spent my time trying >>> building libraries used to abstract higher functionality for cross-plat= form >>> compatibility. And, until now, that's primarily been in C -- shell is o= nly a >>> recent excursion because I feel I've *finally* nailed the right recipes= for >>> that. >>>=20 >>> I'm actually a bit worried that Python and Lua don't have the reach tha= t C does, >>> let alone shell. >>>=20 >>=20 >> +1 to a well-reasoned and insightful post. >>=20 >> What are your thoughts on the other part of Mr. Perlstein's concern: the >> lack of what I would like to call a Grand Unified Schema? Perhaps such >> a thing belongs in POSIX as well, as it would be intriguing to be able >> to write tools (in whatever language) that could rely on uniformly >> parseable data (i.e. sizes always known to be in eight-bit bytes, text >> in UTF-8 [let's say], time in seconds, numbers in decimal without >> commas, key-value pairs in a specified format, consistent meaning for >> key names). -- George >=20 > Hi George, >=20 > I'm glad you asked. My experience tells me that 90% of the Grand Unified Schema is adapting a single interface so that the following two issues are dealt with: 1. The issue of consistency that arises when two or more programs (often perhaps in two or more languages) are tasked with parsing the same data. 2. The issue of stability that arises when a program must make decisions when changing data that is originally written by a human. A recent example of #1: - /boot/loader.conf is parsed by /boot/support.4th written in Forth - /etc/sysctl.conf is parsed by sysctl(8) written in C While some folks may view these files as separate and unrelated (perhaps making it OK that they are parsed differently with different rules), I find that the files play a role with one another. For example, in writing a tool to determine the value of a runtime tunable, I should check both loader.conf(5) and sysctl.conf(5). But alas, they have different parsers with different rules. A recent example of #2: All too often, when a program edits your human-crafted config, it is unkind to the formatting that was artfully applied (especially considering whitespace; but the list goes on). That is to say, that if the Grand Unified Schema simply attacks those two issues by: 1. Centralized parsing library 2. Centralized mangling library I recall something similar in iOS Core Data Stack implementation... Using NSManagedObjectContext, NSPersistentStoreCoordinator, and NSManagedObjectModel you would stuff NSDictionary items in by key. The advantage of the Core Data Stack using the Persistent Storage Coordinator was that (like a UI binding; but instead a Data binding) as you changed memory values, the stored data was updated too. Gratis. For free! (and Free is always good) However, that paradigm doesn't really work in the situation where you want to maintain a human configurable format for your data. It would be interesting however, if we could follow the same idea of a "data binding". The library that implements this would have to keep the door wide- open for customization (as in aforementioned "libfigpar", for example, the ability to wholesale customize functionality by providing function pointers to custom code). And that brings me to the discussion of "the other 10%" of the Grand Unified Schema. NB: Maybe it's more like 99% and "the other 1%" There will always exist some edge-case to which the existing functionality is improper or undesirable. So that's why I think the design should be (for lack of a better description) "pluggable". In libfigpar, that means passing function pointers for call-backs. That just happens to be how I like it in C, but I'm open. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EE82B0A-44A1-4B0E-94F0-C101625108AC>