>
> 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.
>
The is where all of the commercial work on "agents" is going -
the client sending code to the server. This is largely because
they are targeting the disconnected mobile user and the
low-bandwith connected home user. This is exactly what Telescript,
etc. is supposed to do. ( With a lot of commercial hooks most of
us university internet folks haven't addressed much yet: how to
specify "and I don't want to spend more than $NN on this search,
and here's the billing authority. You may pass this charge token
on to other servers as long as all requests do not exceed $NN. )
I DON'T know if they have looked at the problem in the other
direction at all - the server sending code to the client. But
for mobile users, with small memory machines and no simple way
of adding yet another viewer when required, it would seem to
make sense for them to allow this also. "Oh - you don't know
how to handle gsm compressed audio ? well, here's the code to
decompress it... " - i.e. the PostScript model - don't send
the bitmap, send the instructions to create it.
-- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU> --
-- UVA Department of Molecular Physiology and Biological Physics --
-- Box 449 Health Science Center Charlottesville,VA 22908 --
[ "Cheese is more macho?" ]