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

Different apps have different needs

Expand Messages
  • Jeff Bone
    ... Okay, so here s the conclusion I m coming to --- all of the various options we ve been discussing are appropriate in different application contexts. None
    Message 1 of 4 , Feb 3, 2002
      "S. Alexander Jacobson" wrote:

      > At least with HTTP/XML, you get some bonus in
      > deployability/flexibility. With one shot
      > notifications, you don't. Worse, with One-shot,
      > you need a new HTTP method!
      >
      > The semantics of GET Events are cleaner. It
      > is more deployable. It is more scalable. And, it
      > is more consistent with the way the web already
      > works.

      Okay, so here's the conclusion I'm coming to --- all of the various options we've been
      discussing are appropriate in different application contexts. None of them is
      universal --- as Paul points out, viewing a chat room as a caching problem is probably
      not the right answer, but OTOH presence is *very much* a caching problem. For a chat
      room, you most likely need a "centralized" resource that reifies the room and manages
      mux/demux/ordering of arriving messages. For presence, a resource models a particular
      person's status and cache invalidation is appropriate, update an optimization. For
      IM, it's probably the case that a simple POST is appropriate. (Rollover from IM to
      chat is then cleanly handled by a 3xx redirect in response to a POST, with a header
      indicating that a long-lived GET on the indicated resource should be established.)
      For syndication, cache invalidation is the right option, and update via a pushed state
      representation an important optimization. For Web-based distributed storage, again
      cache invalidation is probably the right option. For stock quote streams, long-lived
      GET is probably the right option. Etc., etc., etc.

      Long-lived GET is appropriate in two contexts: first, where the problem you're
      actually solving is the asymmetry of connectivity on the Web, and then long-lived GET
      only solves half the problem, and that rather poorly. Second, when the resource model
      of interest changes frequently and ordering of those updates is important.

      The problem, though, is that (particularly in the second case) the mechanism for
      framing and delivering events over a long-running GET is (a) not specified by HTTP,
      really --- there are no existing suitable mechanisms for passing *multiple* responses
      to a single request, though pipelining could potentially be abused somehow, and (b)
      even if there were, the problem seems very application-specific; knowing what
      individual update messages or events mean, etc. may not be generalizable. To the
      extent that it is generalizable, KN or similar probably provides the right general
      pattern.

      Just some thoughts... mulling over a whole can of worms that I'd been mostly ignoring
      for the last few years... ;-)

      jb
    • S. Alexander Jacobson
      ... HTTP fundamentally differentiates between clients and servers. It specifically does not require clients to implement server functionality. A client should
      Message 2 of 4 , Feb 3, 2002
        > Long-lived GET is appropriate in two contexts: first, where the problem you're
        > actually solving is the asymmetry of connectivity on the Web, and then long-lived GET
        > only solves half the problem, and that rather poorly.

        HTTP fundamentally differentiates between clients
        and servers. It specifically does not require
        clients to implement server functionality.

        A client should not have to implement server like
        functionality if it is just receiving
        requested state from a server.

        Assymetry is part of the HTTP model. Enjoy it!

        > Second, when the resource model
        > of interest changes frequently and ordering of those updates is important.
        > The problem, though, is that (particularly in the second case) the mechanism for
        > framing and delivering events over a long-running GET is (a) not specified by HTTP,
        > really ---

        I agree with you. My general claim is indeed that
        this is a problem to be solved at the content-type
        level rather than at the HTTP protocol level.

        And, moreover, the combination of
        multipart/mixed with message/external-body has
        exactly the semantics that notification
        requires.

        There is no deep need to reinvent the wheel.

        > there are no existing suitable mechanisms for passing *multiple* responses
        > to a single request, though pipelining could potentially be abused somehow,

        I am not advocating passing multiple responses. I
        am advocating passing a single multipart/mixed
        response (that may be sent chunk encoded).

        > and (b)
        > even if there were, the problem seems very application-specific; knowing what
        > individual update messages or events mean, etc. may not be generalizable. To the
        > extent that it is generalizable, KN or similar probably provides the right general
        > pattern.

        I don't know the details of the KN protocol, but
        the application of getting notifications of change
        on some set of URLs is best handled by MIME.

        You need to get the MIME zen. :-)

        -Alex-


        ___________________________________________________________________
        S. Alexander Jacobson i2x Media
        1-212-787-1914 voice 1-603-288-1280 fax
      • Lucas Gonze
        ... I agree. I am excited to work on changing that but also uneasy about it.
        Message 3 of 4 , Feb 3, 2002
          > HTTP fundamentally differentiates between clients
          > and servers. It specifically does not require
          > clients to implement server functionality.
          ...
          > Assymetry is part of the HTTP model. Enjoy it!


          I agree. I am excited to work on changing that but also uneasy about it.
        • S. Alexander Jacobson
          ... Why change it? -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914
          Message 4 of 4 , Feb 3, 2002
            On Sun, 3 Feb 2002, Lucas Gonze wrote:
            > > HTTP fundamentally differentiates between clients
            > > and servers. It specifically does not require
            > > clients to implement server functionality.
            > ...
            > > Assymetry is part of the HTTP model. Enjoy it!
            >
            >
            > I agree. I am excited to work on changing that but also uneasy about it.

            Why change it?

            -Alex-
            ___________________________________________________________________
            S. Alexander Jacobson i2x Media
            1-212-787-1914 voice 1-603-288-1280 fax
          Your message has been successfully submitted and would be delivered to recipients shortly.