Moving on

Gerard Beekmans gerard at
Thu Jun 14 17:33:42 PDT 2001

> It's XML, almost every single language has a way to parse it and could
> in fact either become a fe or be, with a little hacking, if it was done
> in a shell script, we would be limited to that single interface. (that
> being a shell)

[Disclaimer: I don't really know what I'm going to talk about, so if you
want to correct me so I finally _do_ know what I will be talking about
in the future. Right now I'm just going to write down what my gut tells
me. I'll be writing as if I'm the expert (makes it easier to write
instead having to add "I think" or "I believe" or "something to that
effect" every other sentence ;)]

One of the barriers shell scripting introduces is when we need it to
communicate with a front-end. Ideally we won't have to run the backend
or even know it's there. We start out front-end, say QT based, and click
on a "Start install" button. How would we have bash talk back to the QT
app? As bash has no XML support I'm aware of, it'll have to resort to
echo'ing a status to a file, stdout, stderr, or QT's stdin and QT will
have to interprete that 'echo' and do something with it. This becomes a
little bit harder when it has to be done over a network. I suppose bash
could start a c program that makes a network connection to the QT app,
dumps some status message, waits for reponse. To me I guess this would
need to be a continuous open socket so the fe and be can send message at
any given time.

I also see problems with bash waiting for input. Perhaps an extra daemon
can SIGALRM1 bash or something. That i won't begin to guess.

So I guess technically we could stop using XML and start using shell
scripts, but when we get to networking support I'm afraid bash won't
meet our goals. If we were to use XML-RPC (or RPC-XML; whichever way) we
could tell QT "interrupt backend, send this new profile". Over RPC-XML
we send an XML profile, be gets it, does not need to do anything with,
can run it immediately (then again you could tell the RPC thing to just
send a bunch of command sequences to the shell on the other side and
tell it "run this, until  EOF.....commands.....EOF".

Would it be feasible? 

Gerard Beekmans

-*- If Linux doesn't have the solution, you have the wrong problem -*-
Unsubscribe: send email to alfs-discuss-request at
and put unsubscribe in the subject header of the message

More information about the alfs-discuss mailing list