- From: Steven D. Majewski <sdm7g@virginia.edu>
- Date: Thu, 9 Mar 1995 11:22:18 -0500 (EST)
- To: Nathaniel Borenstein <nsb@nsb.fv.com>
- Cc: Multiple recipients of list <www-talk@www10.w3.org>
On Thu, 9 Mar 1995, Nathaniel Borenstein wrote: > Excerpts from mail: 9-Mar-95 agents [was: Client-Side Sc.. "Steven D. > Majewski"@vir (10767) > > > Nathaniel Borenstein has argued for a procedural language (safe-tcl) > > because he's not quite sure what *exactly* he wants to do. (That is also > > why I'm experimenting with Python agents. ) However, it is just that open > > endedness and lack of standard higher-level functions that makes it > > not, in general, practically safe. > > I think this is not quite an accurate representation of my position, > actually. I've argued for a procedural language (safe-tcl or something > better, if it comes along) because I want people to be able to do the > maximal possible number of things safely. It isn't that I'm not sure > what *I* want to do, it's that I am absolutely sure that nobody knows > what *everybody* will want to do. For that reason, my focus has been on > providing the maximum amount of expressive power that is compatible with > a safe language for untrusted scripts. > You are correct Nathaniel: that was *not* an accurate representation of your position. Sorry - my note was long enough without including another bunch of quotes, and I assumed my interest in working on Python agents would imply my sympathy with that position - i.e. it's also my own. Dave Crocker also took exception to my choice of the pronoun "he" . I certainly did *not* mean that to be read as "N.B. doesn't know what he's doing" ! And in fact, your words are a more accurate description of my own views. > > In short, a safe language infrastructure is primarily a tool for the > cutting edge, to streamline and speed up the refinement and development > of new services. I predict that many of the most successful > applications of such languages will lead directly to new data types that > permit the applications to be implemented WITHOUT the safe language, > because there's probably always going to be more expressive power > available that way. But the overhead of installing support for such > things in a zillion different systems is very high. A safe language > will permit a lot of services to be developed and played with in > *advance* of such domain-specific code installation. > All of which I also agree with: when I used the word "research", I didn't mean two-people-with-a-grant-in-a-room but hundreds-of-people-on-the-net! ( And, eventually, with a good & safe enough distributed language, why would there be a reason to migrate to the non-procedural protocol? ) > Of course, you still need to get the safe language installed everywhere, > e.g. in all the web browsers. But once you do that, you can experiment > with advanced services much more easily, and thus start to convince > people about what advanced services are most important, and that's the > major point. One of my points was that without standard libraries for doing Web like things, and maybe also - at least on the server side - protocols for agent interaction, or minimally something like TeleScript tickets (or whatever they call them), we're not quite ready for distributing it to hundreds of people on the Web, let alone wide scale commercial distribution. Safe-tcl ( or Python, or scheme or Oblique or any of the other erperimental distributed languages ) are currently too low level to be installed in all the web browsers and used safely. ( Safe-Tcl + standard high level set of services/libraries *may* be high level enough - or we may have to cycle thru another generation of experiments to get it right. ) I don't mean that all advanced services have to be pre-defined, but there has to be a useful core set. ---| Steven D. Majewski (804-982-0831) <sdm7g@Virginia.EDU> |--- ---| Computer Systems Engineer University of Virginia |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| Box 449 Health Science Center Charlottesville,VA 22908 |---
Received on Thursday, 9 March 1995 11:55:36 UTC