[cc:'d to uclinux developers to get their input.]
[My original message is duplicated here at the bottom of this message.]
I think I need to be more clear on what I meant by my "embedded
application shell". Some people suggested expect, others cron. These may
certainly be part of the implementation of such a shell, but what I am
thinking about it something more integrated and even (ye gods!) more
userfriendly. It probably wouldn't be appropriate for real-time
applications or near-real-time sensing and monitoring units. (But it may
make prototyping of such systems faster.)
As it stands today, whenever anyone wants to build an information kiosk, a
network thin server (like the Cobalt Cube), or some other computer system
where the purpose of the computer is not to be a general purpose
workstation, but to have a certain, specific function, they must write not
only thir primary application, but all the supporting, monitoring, and
displaying code.
For example, I've seen MP3 players for someone's car. Although it would
be very cool, I wouldn't want to have to telnet into my car to restart
'freeamp' or 'mpg123' because of some error. And I'd like some standard
way of capturing return codes and other system messages, parsing them, and
controlling system response to system messages. (syslog-ng would work well
here--it can redirect syslog messages to different outputs based not only
on log level but on regular expression pattern matches.)
I also wouldn't want a user to muck about with her startup files. Think
"At Ease" if you ever used a Macintosh. "At Ease" was (is?) bascically a
menu of applications you could launch. It prevented acces to the system
folder and even the hard disk. Granted it wasn't perfect, but it kept
things on the desktop sane. The embedded app shell would do similar
things--it could provide a menu of commands to be launched and restrict
the user's ability to screw up their session. (A simple quota for this
account would be part of this solution, but the embedded app shell would
be responsible for making sure the quota is set up correctly.)
This embedded application shell would also function as a watchdog,
restarting (and/or sending alerts) for a predetermined set of applications
(like freeamp in the above MP3 scenario).
It would have a graphical mode (for info kiosks and web-surfing stations),
a text mode (for things like ATMs or anywhere graphics are overkil), and
HTML output mode (for things like network thin servers), and maybe even a
non-output mode (for devices with a 1 or 2 line LCD screen, which would
presumably be under strict control of whatever application is running).
There would need to be a well thought-out modular architecture to this
shell, which is why I bring the idea to this list for discussion. It
would need a display subsystem (graphical, text, web, and none), a
"launcher" subsystem, an error handling subsystem, a "pre-requisites"
check (to make sure network is up if needed, that quotas are are set, if
certain necessary apps are running, etc), and maybe some kind of
config-file management subsystem (if we can come up with one paradigm to
handle every possible config-file syntax, I'll be really impressed).
What else would make it more useful?
It strikes me that GGI might be useful here for the display subsystem. I
have no idea how big their libraries and kernel patches are, so I don't
know how suitable they'd be for some embedded systems. They've done work
on seamlessly modularizing display output. For example, they have an
X-Windows target and an ASCII target. One application that uses GGI can
be rendered in an X graphical environment, or via ASCII art on a terminal.
I think one good determination of how well the project is getting along
would be how useful it would be on the Linux port to the Palm Pilot.
Linux on Palm is really cool, but at this point it is nowhere near as
useful as the PalmOS, simply because command-line (while I love it)
doesn't work too well on a PDA.
I'd really like to hear everyone's experiences with running embedded
applications. Also, I'd like to hear if I have made my "vision" clear, or
if I am just babbling like a baboon :)
--Jeremy
On Thu, 25 Feb 1999, Jeremy Impson wrote:
> Does anyone know of any work done to create an "embedded application
> shell"?
>
> By this, I mean some curses- or X-based (or both) application that can run
> as a shell around other applications. For example, if I wanted some kind
> of public Internet kiosk, I might build some PC104 or DIMM PC-based
> hardware, put Linux on it, then run this embedded shell which wraps around
> an email client (Mutt, Pine, Emacs), a web browser (Netscape or lynx). It
> would basically be a menu-based program launcher with robust error
> recovery features, so if something like Netscape crashed, it would return
> a useful error message, and maybe even some alternatives (such as Lynx or
> Arena), as configured by the administrator.
>
> It should have limited environmental control and maybe some file
> management. Midnight Commmander might work with this.
>
> It might be able to detect whether the local network is working before
> launching a web browser. It could have a whole slew of dependency checks
> (i.e. don't run web browser without network, make sure we have dial-tone
> before dialing, etc.). These could be separate applications that are
> called by this shell.
>
> Of course, it should be able to run in a chroot environment if required.
>
> It would be tempting to make it all web-based, but then you would have
> problems with launching curses-based terminal programs.
>
> Ideally (and probably not too difficultly) this shell would run on any
> Linux port, so the VME, Dragonball, StrongARM, etc, ports would benefit.
> Such a shell would be useful not only for kiosks but for PDAs and for
> network blackbox servers (like the Cobalt Cube).
>
> Any thoughts?
>
> --Jeremy
>
> Jeremy Impson
> Network Engineer
> Advanced Technologies Department
> Lockheed Martin Federal Systems
> [EMAIL PROTECTED]
>
Jeremy Impson
Network Engineer
Advanced Technologies Department
Lockheed Martin Federal Systems
[EMAIL PROTECTED]
