Loading ...
Sorry, an error occurred while loading the content.

Async confusion

Expand Messages
  • Jeff Bone
    I think we re getting a little bit confused re: what async means in this context. There are at least two orthogonal dimensions of interest: asynchronous
    Message 1 of 1 , Jan 17, 2002
    • 0 Attachment
      I think we're getting a little bit confused re: what async means in this context.
      There are at least two orthogonal dimensions of interest: asynchronous communication
      of request and a possible future response stream, and asynchrony -wrt- connectivity at
      a given point in time, i.e., the idea that the sender and receiver must be able to
      communicate at a given instance, hence must both be online.

      The first is simply "callbacks" --- even pub / sub, watching, etc. is a higher-level
      metaphor over simple callbacks. Callbacks have no topological implications / require
      no new connector types and --- as Mark points out --- don't even require protocol

      The second is store-and-forward, where the sender and receiver need not necessarily
      have instantaneous connectivity. Store-and-forward requires a number of things: more
      complex intermediary services, a notion (at least minimal) of routing, etc.

      Just a point of clarification --- these are independent things. Another interesting
      semi-related thing to consider is the impact of communication *assymetry* --- the fact
      that sending and receiving roles are not the same as connection initiator and
      connection receiver, i.e. "client" and "server."



      Mark Baker wrote:

      > > Mark,
      > >
      > > Something like WATCH is definately part of the solution! But it is only part of
      > > the solution -- there is much new code to be written to make it work. For
      > > example,
      > >
      > > > WATCH http://www.yahoo.com HTTP/1.1
      > > > Reply-To: http://mysite.org/yahoo-watch
      > >
      > > You are assuming that this call can be emitted synchronously. Before the new
      > > WATCH method can solve anything, it has to be received.
      > True, but I don't say *who* has to receive it!
      > > What if the caller, the
      > > caller's proxy, or the recipient is temporarily offline?
      > Then let the recipient have a proxy that queues up these requests.
      > > In the context of
      > > request/response, you only emit calls that make sense if they complete in the
      > > present. In the context of publish/subscribe you may emit calls that don't have
      > > any results until a fuzzy point in the future, so it may not matter if the call
      > > is emitted immediately.
      > Ok.
      > > In the above example, the client should be able to cache the call until it goes
      > > online. Such a local cache would be just like a local outbox. That is:
      > > ===========
      > > User software has an application-defined need to send a subscription message.
      > > This might be an application subscribing to a stock ticker. The user software
      > > finds that the user is offline, hence the message can't be sent. It caches the
      > > message and initiates a polling loop against the remote resource provider.
      > > ===========
      > Right. See above.
      > > Notice the similarity with a mail user agent attempting to publish a text
      > > message via email. The sending application should not do the polling, because
      > > there may be many such sending applications. Instead the sending application
      > > should submit the send to a system-wide outbound queue and leave the polling to
      > > a single daemon.
      > >
      > > ===========
      > > An application publishes a subscription message to a stock ticker. Because the
      > > endpoint is offline, the message is submitted to an outbound queue. A daemon
      > > minding the queue and polling to discover online mode eventually finds that the
      > > endpoint is online. However the ticker publisher is not online at that moment.
      > > The daemon submits the subscription event to a third party dropbox maintaned by
      > > the ticker publisher.
      > > ===========
      > >
      > > Again, these semantics are covered by mail infrastructure already but not by web
      > > infrastructure.
      > You sure about that?
      > > Let's not get bogged down in this slightly wierd point that email is more RESTy
      > > than the web. The first point is that _sender_ asynchronicity means assuming
      > > that every single hop may be an emission that requires store-and-forward.
      > > KnowNow's architecture requires a special new server, the event router. What is
      > > an event router but a store-and-forward node? (uh, well, it's also a topic
      > > coordinator. That's too big a can of worms for this message.)
      > Heh. It's just a web app, nothing more.
      > Pipeline + statelessness = great (email)
      > Pipeline + statelessness + generic semantics = awesome (Web)
      > MB
      > --
      > Mark Baker, Chief Science Officer, Planetfred, Inc.
      > Ottawa, Ontario, CANADA. mbaker@...
      > http://www.markbaker.ca http://www.planetfred.com
      > To unsubscribe from this group, send an email to:
      > rest-discuss-unsubscribe@yahoogroups.com
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    Your message has been successfully submitted and would be delivered to recipients shortly.