[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Structured (XML-like) input/output for shell apps?



* Olaf ::

> On 6/13/05, Humberto Massa Guimarães <humberto.massa@almg.gov.br>
> wrote:
> > Yes, and I withdraw :-) what I said about XML. But *any*
> > serialization / deserialization necessary for this scheme to
> > work would add (unnecessary) overhead. This and the fact that
> > you would
>
> Well, if you can do it with Perl without overhead, you can of
> course also do it without Perl without overhead.  In that case the
> 'structured' support would be included

Not exactly. Don't get me wrong, object component technology is a
great thing, standing just next to sliced bread in the list of great
things, but (just like sliced bread) it does not cure cancer.

When I do my example inside of Perl, I am supposing whatever objects
or handles the Perl interpreter has stay inside the interpreter's
process; when you do a pipe like

monad-ls *.ab | monad-fields name, size | monad-tableout

you are implying the existence of 3 processes, two of them making
serialization of their (internal) objects for output, two or them
making de-serialization of their inputs to (internal) objects, all
of them analyzing (or receiving a hint from the shell, that had to
analyze for them all) to see if their input came from an object
pipe and if their output goes to an object pipe. At least two of
those process have to read all of their input to memory before
spitting any output (ls -- because it sorts the filenames -- and
tableout -- because it dimensions the columns beautifully).

This is a *lot* of overhead -- normal overhead, contention overhead
(ls blocks the other two processes until it starts spitting its
output), and synch overhead (any object read in the input must be
perfectly synchronized to be a valid IPC object), and it's a lot of
overhead independently of the IPC mechanism utilized.

In the case of my Perl example, verbosely made to use a hypotetical
text::table:

use Text::Table; $t=new Text::Table;
$t->addline($_, -s $_) for <*.ab>; print $t->as_text

You still have some contention inherent to the operation you want to
convey (sorting *.ab, determining optimal column width), but none of
the (really expensive) freeze-serialize/deserialize-thaw cycles the
monad version has, nor the (expensive, complex, and even with
security implications(*)) input-format, input-synch, etc issues.

(*) security implications because when you make a pipe component
like monad-fields that can receive an arbitrary object as its input,
you have to have in mind that said object can have security bugs in
its methods, either on purpose or not. Imagine a malicious-ls that
spits objects whose "get-name" method (property getter) copies the
.ssh directory of the current user to another, publically-readable
locale. This can be installed in someplace in the net and you can
convince people that your ls is better and 0wn the poor bastards...

This *will* certainly happen in an environment like this because,
well, there will be a point in time where it will be too much
trouble to check all those distributed objects... Not unlike a lot
of websites install spyware via ActiveX in the poor IE-using folk.

--
HTH,
Massa



Reply to: