Jeremy Impson wrote:
> But maybe I should scale back the scope of ECS, and just start with a
> pen-friendly GUI with robust error handling.
>
>
> Well, you appear to have succeeded! And for me at least, your sendmail
> problems are fortuitous, because they got me thinking. (A dangerous
> thing :)
>
So now I am thinking of ecs in terms of an environment within an environment, where
I have a simple and robust API with standard methods for exception handling etc
which deals with my app specific stuff, but which can also invoke and interact with
normal unix userland so I may e.g. write a script which wraps a standard app and
maps it to my API, a virtual device driver.
Now ecs is starting to look more like emacs/lisp than senmail.cf and allready I
like it better, and i'm a vi man.
But, the architecture is still not quite right. We are not wanting to embedded a
language in an app but embedd apps within a language. If we started by tacking
somthing like PERL or Python and incorporated our API into it, it perhaps would not
be far off. But these languages are big, also because they have many things like
floating point that are just not needed at this level, whilst the resources used
would be incompatible with many embedded systems.
So, lets go back to the command shell, for a moment anyway. Let's start with ash
(but with simpler cleaned up syntax because sh compatibility is a non issue here).
Now, we have allready discussed how the role of a command shell is to interactivly
control the users sub-environment, and we have established that this is not what is
wanted because we want an autonomous environment.
So we modify the concept, instead of issueing a command that launches an app and
scrolls the std ouputs on the screen before use, we make a shell that is told to
keep this application running, or run this routine evry 5 mins, or so on, and that
'traps' stderr rather than reguritate it. But we do it by a simple syntax language
rather than config files (you mentioned Turing, and it was he who to all intents
and purposes defined the 'difference' here), but the scripts make simple and easy
use of extensions that perform the things that we would otherwise need to add
(watchdog routines) or set up seperatly (e.g. crond). And as I said, we can use
anything executable to make wrappers for things not designed for our ambient.
Is that unleavend bread I see in my CD-tray...............................
