[5864] in www-talk@info.cern.ch

home help back first fref pref prev next nref lref last post

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 

 

home help back first fref pref prev next nref lref last post