[5864] in www-talk@info.cern.ch
Re: Forms support in clients
daemon@ATHENA.MIT.EDU (Nathaniel Borenstein)
Tue Sep 27 21:56:47 1994
Date: Wed, 28 Sep 1994 02:54:15 +0100
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: nsb@nsb.fv.com
From: Nathaniel Borenstein <nsb@nsb.fv.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Excerpts from www-talk: 27-Sep-94 Re: Forms support in clients Karl
Auerbach@cavebear.c (2188)
> If those documents are to have access to resources outside of those
> they carry along inside of themselves, i.e. if they update shared
> databases or interact with third party machines, the use of security
> gets even more interesting; and I think that it then goes well beyond
> the concept of a neutered "safe" execution environment.
I think you'll find this addressed at least partially by ATOMICMAIL's
file system, Safe--Tcl's distributed libraries, and the Safe-Tcl
two-interpreter extension model. Check it out.
> Then there is the nearly 100% severable issue of clients putting
> things into a server. My favorite example is a periodic polling
> script that would let me know when a new document of a certain type
> appears in the server. This is perhaps a robot issue, but it is
> something I think many commercial users would want. (Or, as a
> scientist, I might want a poll script to watch for new documents which
> pertain to a certain process or which cite some previous document.)
> It is this latter possibility that intrigues me. I don't know that it
> fits very well with the current architecture.
I'm not sure, because I don't understand this example. When the new
document comes to exist, what exactly do you want to happen? -- NB