Jeremy Impson wrote:
> This first sentence illustrates my point. In order to _maintain_ your
> kiosk you had to write your own custom code.
A few lines.
> What I propose is a preintegrated support system, with as much flexibility
> as possible with regards to how it can be deployed.
This implies a complex to configure system, possibly requiring macros, and
almost certinaly more work to set up than just rolling your own. Modified your
sendmail.cf recently?
> > Jeremy's problem is that his way of thinking about computer systems
> > has been corrupted by overexposure to the limitations and
>
> I really take this as an insult! I come from a Unix background. I know
> and understand the Unix toolbox approach. And I advocate it everywhere I
> do any coding or system design. My previous messages have concerned the
> _abilities_ of an embedded application shell, NOT its implementation. I
> don't like giant monolithic apps. I like small, simple, 1-function little
> programs. They are easier to write, easier to debug, and they force the
> system designer to create real, useful, and elegant abstractions. This is
> how I would implement the embedded application shell.
Sorry. BTW, it was the bit about limiting user access that convinced me you were
not Unix savvy.
>
>
> This idea is a shell in concept only. First, it would not be just one
> single executable/script. And it wouldn't be a true Unix shell. I was
> afraid it would be misinterpreted if I named it that, but it really is a
> shell in concept in that it encapsulates the system, and I couldn't think
> of a better name. "Launcher" came to mind, but I was afraid it didn't seem
> general enough.
Good basis for a lexical discussion here. A command shell is really a portal or
a control panel from a system point of view, after all it does not encompass the
system. The term shell is used because it is the container for a user
environment to which commands may be interactivly invoked, and hence we have the
clarifier 'command'. Put another way the term shell is correct, it is the
clarifier command that makes your desires appear contradictory. I think a good
term for your concept is control shell or embedded control shell, or ecs.
> Let me ask Roger this: can you build your kiosk today without having to
> write that custom script that parsed error messages and respawned
> applications? If not, then could anyone use the script that you did write
> for their own kiosks with no logical/program flow alterations, only a
> change of configuration parameters? Does the script work for
> user-interactive apps like Netscape? Does it detect when the network is
> down and give useful error messages to both the user and to the sysadmin?
Read again, and then think how many possible scenarios there are in what you are
suggesting. Our kiosk used dial up connections with SLIP. If dip did not return
an error, we checked the path to the server with ping before proceeding, else we
abort and re-did from start. But that was our case, there are many ways to
network, SLIP on a fixed serial link dial-out PPP, dial-in PPP, LAN, ISDN, X25,
they all require different handling. Then what about those messages? An email,
maybe, an 'xmessage', perhaps, smbclient -M anyone? Then what about Netscape,
this has very handy command line options that allow you to access an already
running netscape session, other programs have such facilities, but done in
different ways. Our you going to handle these possibilities?
If you try to take care of evrything then we are back to sendmail.cf. If you try
to do things in a high level generic manner we are back to scripts.
Look at the difference twixt Windows and Unix. Windows trys to make evrything
set upable by a fixed set of options, but in order to keep things usable the
options must be limited, and thus so is what you can do.
> > So how **do** we do what Jeremy wants? Well, the best I can do is give
> > you some tips and tricks to get you thinking in the right way, then
> > you go and experiment!
>
> And after we experiment (which I assume is what everyone here is doing),
> we should pool our knowledge, then maybe (if we have time and ability)
> contribute our experiences into a product for anyone to use.
>
OK, take the mick, I deserve it. I am suffering from over exposure to people who
think UNIX is like the DOS command prompt with different syntax, and anything
fancy must be done by trickery.
> [snip]
>
> I've cut Roger's excellent implementation ideas, some of which I had
> thought of (using FIFOs), some of which I hadn't (like using netpipes).
>
BTW, netpipes are a security issue, use for intranets only. Also, as somebody
else has allready pointed out to me, inetd is not that much more difficult to
use, and is more elegant/versatile.
>
>
> And if it is done correctly, it would be easier for them to set up and use
> this shell than it would for them to write their own code.
Why?
> And they won't
> need to "know how to exploit the facilities of UNIX".
They will need to know if they are going to develop thier app specific code.
Plus they will need to know how to use the facilities of 'ecs'.
> We know how, we
> exploited them, and we make them easily used by others.
So we build a library of an example scripts to serve as a starting point.
>
>
> Writing an application that runs on bare metal is easier than writing your
> own Unix kernel, userland libraries and apps, then writing your own
> application.
Whoa...steady on, we required a couple of simple scripts, I think inferring you
need to write your own Unix kernel is going a bit too far. As too wether it is
easier or not, I wouldn't know. I must remeber to ask Linus this one.......
> But, using the kernel, libs, and apps that someone else
> wrote and just writing your own application is easier still.
Not neccessarily so. I keep mentioning sendmail.cf because sendmail is a program
that can be set up to do just about any mail server configuration, but as a
consequence is extremely difficult to configure. Result, you find mail
administrators using scripts to do tasks that sendmail **could** do, but
requires so much 'configuring' to be able to do it that the script option is
easier.
> As a test situation, a minimal implementation of this embedded app shell
> would be able to do this: With no extra coding, a competant Unix
> administrator should be able to set up a Linux box and install the EAS.
> The she would be able to make it an email kiosk by editing a configuration
> file that says "run Mutt, keep an eye on it, make sure that the network is
> up and the POP server is running". Later on, the admin can change the
> configuration (again, with no code changes) so that it runs Netscape mail
> in X instead of Mutt and keeps an eye on both X Windows and Netscape. No
> other changes.
>
I certinly think our ideas are convergent. You see I am not against 'ecs', but I
think it must be simple. I still think along the lines of a fine grained crontab
with a few extras such as ;always_running <this_prog>' and :
If [this_script ruturns this], then launch this
The latter is getting us back to scripts in general, but doing things this way
would encourage people to use a set of mono-function scripts rather than
multi-function scripts, and thus that would render them far more suitable for a
modify and re-use script library.
Now, if only I can get this **(*&&^%$$#** sendmail configured I will post this
reply.................
