On Tue, 5 Mar 1996, Roger Irwin wrote:
> > 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?
I'm beginning to see your points. There is a continuum here: on one end
lies a completely programatic solution--write your own shell script/perl
script/C program. This is very flexible, (sometime) very lightweight, and
easy to maintain (by people familiar with the code). On the other end
lies a "monolithic" system where everything is controlled by a
general-purpose application. The person(s) using it in an embedded
application don't have code anything, and what configuration options exist
are easy to understand. But there is no flexibility and no room for
extension.
Somewhere in the middle is something like sendmail. You aren't required
to write custom scripts/apps/sendmail.cf files for most cases, but the
option is there. But in order to keep the flexibility, the configuration
options are horrendous. (sendmail.cf syntax is Turing Complete, which
means it is a full-fledged (if painful) programming language.)
Personally, I like the first extreme. But my experience at my place of
work shows me that many people don't. ("We don't program!") We (the
"corporate We") like the second extreme, but only as long as the original
programmers planned for every use We have might have. Sometimes this
happens, but not often.
So is sendmail the only possible middle ground? I hope not. But now I'm
not sure. In the Embedded Application Shell, the configuration file(s)
could easily get just as complicated as a sendmail.cf file, something I
hadn't thought enough about.
[snip]
> Sorry. BTW, it was the bit about limiting user access that convinced
> me you were not Unix savvy.
In something like a kiosk, the point of the computer is not to be a
general purpose computing/communications machine, so limiting user access
is, in my mind, perfectly appropriate. On my desktop or my server, forget
it!
> 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.
I agree with your lexical analysis, except to say I never called this
wacky idea a command shell :) I said "embedded application shell". But I
like "embedded control shell" even better!
> Read again, and then think how many possible scenarios there are in
> what you are suggesting. Our kiosk used dial up connections with SLIP.
[network connectivity and messaging scenarios snipped]
> but done in different ways. Our you going to handle these
> possibilities?
Yes. But in a modular fashion. But again, your sendmail.cf example makes
me want to rethink everything.
> 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.
You are very right. But I still feel that that en embeddable control
shell can be useful.
I think the thing that first got me thinking about this project was the
PalmPilot. For anyone who hasn't researched into it, it runs what 3COM
calls PalmOS. But in truth, it runs a microkernel called AMX from a
company called Kadak (http://www.kadak.com). Then on top of this, 3COM
(wel, Palm Computing) layered something similar to the ECS that they call
PalmOS.
I don't know anything about the tha AMX kernel, so I don't know if it is a
true microkernel (I don't know if it does high-level I/O or filesystem
access). But PalmOS' biggest function to to provide a GUI, libraries for
doing windowing, searching, and IPC. Basically, it does what ECS would
do. However, it requires that you write applications to its API, and do
things "the Palm" way--event driven with some really funky required system
calls in PalmMain() that if you don't do it right, you can lock the system
requiring a memory wipe and a hard reset :) I don't want this. I want to
use standard Linux apps.
Then I looked at PalmLinux. Having Unix on the PDA is neat, but not
necessarily useful. Having an OpenSource OS and operating environment on
a PDA would be neat and useful. This operating environment may or may not
be graphical, but would be conducive to situations where I/O is not
"standard" i.e. in wearble or mobile computers, where keyboard are out; or
on PDAs where the you want to minimize the number of "taps" (pen clicks)
for the sake of efficiency; or you have an embedded system where the I/O
are four buttons and a single-line LCD display.
But maybe I should scale back the scope of ECS, and just start with a
pen-friendly GUI with robust error handling.
[snip]
> Now, if only I can get this **(*&&^%$$#** sendmail configured I will
> post this reply.................
Well, you appear to have succeeded! And for me at least, your sendmail
problems are fortuitous, because they got me thinking. (A dangerous
thing :)
--Jeremy
Jeremy Impson
Network Engineer
Advanced Technologies Department
Lockheed Martin Federal Systems
[EMAIL PROTECTED]
