>
> To make *any* remote execution system safe, the functions and capabilities
> have to be standardized on a higher level.
This is a long reply to a long post to many lists so I am summarizing
the ideas at the top.
This will allow you to hit delete right away.
This message contains suggestions for developing ideas mentioned by
Steven along the same lines but with some very specific implementation
details included.
Summary :-
---------
Separate out the "safe" functionality in safe-tcl from the generic language
facilites.
Put the "safe" functionality in a set of libraries ( locally extensible )
in an Agent API.
Define an intermediate language ( agent-lingua-franca ) which is the content
of the enabled mail message. All "favorite" scripting languages will
be converted to agent-lingua-franca by MUA extensions.
Agent-lingua-franca is the output of client-side MUA's.
Agent-lingua-franca is the input to the host side facility which
receives the message.
An agent-lingua-franca interpreter at the host side converts it
into usual generic language operations like control flow, variable manipulation
etc. + calls to the standard Agent API.
Back-end the client-side enabled-mail creation facility with a lingua-franca
converter which converts my favorite religious language to lingua-franca.
Front-end the host side "safe" facility with an agent-lingua-franca interpreter.
Incoming enabled mail is un-MIME'ed and then fed as a script to this
interpreter.
Why create "yet another language" when safe-tcl will do ?
Well, safe-tcl won't do, except for those who already like safe-tcl.
There are hundreds of thousands of people who program for a living and would
like to use their favorite scripting language to do enabled mail.
An intermediate language let's them do that.
End-of-Summary
--------------
In your message you, Steven D. Majewski, said in most eloquent fashion
>
[...]
>
> To make *any* remote execution system safe, the functions and capabilities
> have to be standardized on a higher level.
Being familiar with the MS Windows side of things and being a lurker
on this list I have been thinking about the "agent-language-standard"
issue for a while and have come to the same conclusion.
While other Object technologies like CORBA, DSOM, OpenDoc have been
mentioned, one approach worth noting is that taken in OLE2.0.
I am not an MS fan, nor a Windows-only developer, I came across this
technology as I had to write a requirements spec involving OLE2.0.
In the OLE2.0 approach, all object facilities are provided in libraries
and the calling interfaces are published as the OLE 2.0 Spec., as a
binary standard ( without language bindings ) ie a way to push and
pop on and off the stack.
The libraries created by MS are considered *one* implementation of the spec.
In this way
1) Other implementations of the spec can be created.
2) The facilities are available in a language independent fashion - use your
own favorite scripting language.
3) The facilites can be added incrementally as they are available in
a number of DLL's, grouped by subfunction.
This, in my engineering opinion, is the way to go for agent functionality.
I will elucidate further, but we take a break now for flamers to
let off steam ( is that a mixed metaphor ? )
[...]
> If we had a requirements analysis of these higher level functions, then
> it wouldn't make much difference what particular language syntax was
> used - in fact, the higher level you go, the less it needs to be
> considered as or implemented as procedural language.
We agree here.
> Nathaniel Borenstein has argued for a procedural language (safe-tcl)
> because he's not quite sure what *exactly* he wants to do.
I don't want to speak for Nathaniel but I'd like to put in my 2c worth as to
why a single language is not only a "Bad thing" ( TM ) but if one proposes
a single language philosophy then safe-tcl will lose. This will
happen simply because of the
sheer volume of users of say Visual Basic if MS were to push it as the
"agent language" along with some half baked modifications and extensions
to MAPI etc.
General Magic's Telescript also shows such things are possible.
Besides, it is simply impractical to expect programmers with investment
of time in their favorite language, to switch over to safe-tcl when
they don't quite understand the technical reasons. Note that all the people
I am referring to in the above statement are not subscribed to this list
and will pick up something incrementally close to what they understand
rather than make a complete context switch.
On the other hand, take the example of BSD sockets. By creating a
call level interface - Winsock, sockets functionality and in effect
access to a whole new area of programming was made available to a
very "different" community of programmers, with tremendous success.
This leads us to the dreaded "A" word. Do I dare utter it in these
hallowed corridors ... ? API - there I said it. API, API, API.
I'm still alive :->.
Perhaps, what is needed is a set of function calls, described as an
API, that provide the core of what is considered "safe" functionality.
While safe-tcl extensions are a way to extend safe-tcl what they are
is a set of function calls added to the original safe-tcl core.
Given this possibility a different problem arises - if people can use their
favorite scripting language how can the site hosting the "safe" facility
know what language to expect in enabled mail messages ?
Will the safe facility become a disjoint union of interpreters for
every imaginable language ?
It's possible, perhaps, to have something like a RMS's scheme idea where
safe-tcl and other languages be hosted by an underlying scheme interpreter -
but this still begs the question. You still need to write the
interpreter for the n'th language before an e-mail message in the n'th
language is received - not something achievable in general.
Now I will really go out on a limb, but this is the only solution to
the problem above ( I believe ) :-
Instead of specifying a single high level language standard - like safe-tcl -
specify instead an *intermediate* language which is the only language
the "safe" host is expected to interpret. the "safe" host interprets this
byte-code-like-but-better language and transaltes it into calls to a
standard set of library calls ( with local extensions ) - the Agent API.
On the mail-sender side :-
The mail sender creates an enabled mail program in his/her favorite
scripting language and submits it to a local client side enabled-mail-byte-code
-language-spitter-outer which of course spits out the standard byte-code-like-
but-better enabled-mail-language.
It is this language, ( intermediate language ), that is sent in the mail
and acted upon at the receiving end.
Now if you want to convert safe-tcl into that language and separate
out the "safe" functionality into an API, that might work.
Anyone want to do a VB-safe-tcl converter ? Telescript-safe-tcl ?
I am not suggesting this for any technical reasons, just for practical,
down to earth reasons, like widespread acceptance in all programming
communities including the PC based MS Windows community, for reasons like
not allowing someone with a larger installed base set the agenda for
enabled-mail, for reasons like not wanting your children to become
Visual Basic enabled MAPI programmers.
>
> In short, I think a standard scripting language without a standard object
> model is pretty useless, so lets propose a standard object model(s)
Yes, that's necessary before creating an API.
Nitin Borwankar,
Principal, Borwankar R&D
nitin@borwankar.com