James Carlson wrote: > Roland Mainz writes: > > Umpf... the actual idea was to find a "free option" which could be used > > to define a new output format for /usr/bin/ls. The idea is to have > > something like this: > > -- snip -- > > $ ls -l -# compound /usr/share/lib/pub/ > > ( > > basename=ascii > > I thought the flavor of the month was XML.
Using XML in this case is very inefficient. > And better still: '-X' is > still unclaimed in Solaris 'ls'. The idea was to get an option which takes an argument defining the format being used. It would not be $ ls -X # for XML output, it would be $ ls -X lsxml ... # (or replace "lsxml" with the format of your choice (e.g. "compound" in the case of compound variable sets), the idea of this option is to open a door for future output format ideas and not close it). > > The idea is to turn the output into a sequence of compound variables > > which are consumed by the shell's "read -C varname" (or a converter > > application which turns this into an XML document, list set, set of > > serialised java variables etc.). > > For good or ill, we already have a fair amount of precedent for direct > XML output from commands (in lieu of anything _really_ scriptable). XML is wonderfull for exchanging larger, complex documents but it is very inefficient (e.g. you have to encode characters, do charset conversions to UTF-8 and back etc. - and that doesn't even count DTD/schema checking) and performance intensive to create and parse. A simply demo which pipes ~~64MB of data through a compound varible needs around ~~17 seconds on my test machine, doing the same with libxml2 needs around ~~290 seconds (our own "Parsifal"-based parser does the job in ~~220 seconds but that's more or less the lower limit possible). > You'd be inventing a new syntax here, Erm... small correction: This syntax exists since 1992. And with the ARC case for compound_var(4) we jump directly to ARC stabilty level "commited" (!!). > and, regardless of its merits, > I'd expect that getting it supported across multiple different > commands would be a difficult and complex task. I disagree in this case. We have a plan for this. And we don't intend to handle all tools, only those defined by the POSIX standard and even there only a special subset. The other applications are handled differently (adapter/filter strategy). > You need to set > precedent, We have already a precedent for such a system: CMS pipelines. The concept of compound variables is a parallel evolution (I didn't even new about this until the Solaris/SystemZ people pointed this out) but it can perfectly act as precendent. > and that implies show why this should be used -- likely > *instead of* XML for many commands. Agreed. > Going forward without that sort of planning would likely leave it just > supported in 'ls' and a handful of other things that you personally > modify ... which would itself be an unhelpful result. It just further > balkanizes the command set. I am not interested in a balkanisation. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
