>
> > 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
>
> This is where the current model breaks down since it is essentially
> driven by client requests. I'd like to be able for my viewer to put a
> "watcher" into a server. Some mechanism, not yet existing, would have
> to be invented to let the watcher tell my viewer that something new
> and interesting (as defined by my script) is out there. Then my
> viewer could have the new document fetched, my coffee brewed, and my
> slippers handy when I got up in the morning.
On Wed, 28 Sep 1994, Karl Auerbach wrote:
>
> I would expect that using e-mail would be difficult to smoothly
> integrate and probably a pain to administer. Rather, I would want a
> more unified and consistent exhange mechanism, so that, for example,
> only one TCP connection need be used.
>
> I'm rather opposed to building world-wide mechanisms using the
> duct-tape-and-bailing wire mechanisms found in e-mail, particularly
> Un*x based e-mail.
Just before the "language wars" broke out, I was thinking of this
problem, and Karl's remarks reminded me of it again.
What we want is a sort of asynchronous callback mechanism.
E-mail is one sort, but it is *too* unboundedly asynchronous
for some requirements.
I see two non-exclusive methods to do this:
1: Client passes to the server, along with the request, a URL (containing,
probably, an explicit port number), and perhaps an authorization cookie,
and any advice or restrictions of when to call back. This URL could
represent the client itself if it has the ability to also listen on
a port, as well as initiating connections. ( it becomes in effect, a
mini, detached (not always available) server. ), or it could represent
a server that is willing to act as a proxy and accept a post, or any
other program that can listen on a socket and follow the protocol.
2: Server hands client a "future" : a URI that is currently unavailable,
but that will be in the future. ( plus optionally and authorization
cookie and schedule advice. ) There should be enough information
returned that a smart client can automagically stash this future
reference away, and do some reasonable polling, based on the schedule
advice. A dumb client should get a refused message, with enough
additional information that a smart user can figure out what to do
by hand - save this URI somewhere and try to access it later.
Which of these methods to use, or whether to use e-mail would need
a negotiation protocol similar to how mime types are handled.
-- 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?" ]