Re: asynchronous callbacks (was: Forms support in clients)
Karl Auerbach (karl@cavebear.com)
Wed, 28 Sep 94 10:07:39 PDT
> 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:
>
> 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.
Sounds like a useful variation. I had trouble in my "assocation"
mechanism mentioned in another message about buffering response
traffic when the other party is down. And I've always thought that
it might be nice at times to let the server hold things and do some
polling as an alternative.
The problem is, how long does the server hold on and wait before
throwing the result away? This is solveable.
--karl--