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

Re: [rest-discuss] Why is HTTP special?

Expand Messages
  • Paul Prescod
    ... The protocol doesn t know anything about RFC2192, does it? ... Don t know what you mean. Can IMAP do content-negotiation so that I can ask for a particular
    Message 1 of 11 , Feb 1, 2002
    • 0 Attachment
      "S. Alexander Jacobson" wrote:
      >
      >...
      >
      > Re URI handling, do you mean RFC2192?

      The protocol doesn't know anything about RFC2192, does it?

      > Re content negotiation, do you mean:
      > Content-type: multipart/alternative

      Don't know what you mean. Can IMAP do content-negotiation so that I can
      ask for a particular message in different content-types depending on the
      client?

      Anyhow, what makes IMAP particularly weak compared to HTTP is that it
      isn't designed to allow the server to do arbitrary computation in the
      generation of responses. It accepts data and moves data but it can't
      generate it without warping the protocol.

      > > > ODBC/SQL is also nice from the perspective you
      > > > give. The problem is that it does not specify a
      > > > way of passing the types of objects!!!!!
      > >
      > > Also not very well geared for large scale, loosely coupled computing.
      >
      > Why?

      Exposing your relational database schema to the world is not good
      encapsulation!

      >...
      > I think it is the main benefit of the protocol and
      > the big problem with most RPC protocols. They
      > don't provide a standard way of representing
      > all types.

      We'll have to agree to disagree. The list of MIME types are part of the
      Internet. Any protocol can easily adopt the relevant ones.

      Paul Prescod
    • S. Alexander Jacobson
      ... Does it need to? What are you trying to accomplish? ... That is the purpose of multipart/alternative. See RFC2046 sec. 5.1.4: Systems should recognize
      Message 2 of 11 , Feb 1, 2002
      • 0 Attachment
        On Fri, 1 Feb 2002, Paul Prescod wrote:
        > > Re URI handling, do you mean RFC2192?
        > The protocol doesn't know anything about RFC2192, does it?

        Does it need to? What are you trying to
        accomplish?

        > > Re content negotiation, do you mean:
        > > Content-type: multipart/alternative
        >
        > Don't know what you mean. Can IMAP do content-negotiation so that I can
        > ask for a particular message in different content-types depending on the
        > client?

        That is the purpose of multipart/alternative. See
        RFC2046 sec. 5.1.4:

        Systems should recognize that the content of the
        various parts are interchangeable. Systems
        should choose the "best" type based on the local
        environment and references, in some cases even
        through user interaction

        > Anyhow, what makes IMAP particularly weak compared to HTTP is that it
        > isn't designed to allow the server to do arbitrary computation in the
        > generation of responses. It accepts data and moves data but it can't
        > generate it without warping the protocol.

        I don't think so. Pick an application that works
        better for HTTP than IMAP. Its just that most
        implementations are designed for actual mailboxes.

        Nothing prevents a server from virtualizing
        "mailboxes"

        Arguably IMAP is nicer in that it more clearly
        differentiates between update and query!

        > > > > ODBC/SQL is also nice from the perspective you
        > > > > give. The problem is that it does not specify a
        > > > > way of passing the types of objects!!!!!
        > > >
        > > > Also not very well geared for large scale, loosely coupled computing.
        > >
        > > Why?
        >
        > Exposing your relational database schema to the world is not good
        > encapsulation!

        Nothing stops you from exposing a view of your
        schema rather than your underlying schema. If you
        do end up exposing your schema, you can always
        expose a view later when you change it.

        Since there is a pretty direct mapping between
        resources and objects in table, I am not really
        sure what you are arguing here.

        > > I think it is the main benefit of the protocol and
        > > the big problem with most RPC protocols. They
        > > don't provide a standard way of representing
        > > all types.
        >
        > We'll have to agree to disagree. The list of MIME types are part of the
        > Internet. Any protocol can easily adopt the relevant ones.

        But they don't. In particular, XML-RPC does not
        use MIME content types. Niether does RMI or
        Corba. SOAP sort-of uses them in the SOAP with
        attachments spec, but it is really an
        afterthought.

        The reason why HTTP and SMTP have been so
        succesful in letting people talk to one another is
        MIME. No non-MIME transport protocol has been
        particularly successful.

        -Alex-

        ___________________________________________________________________
        S. Alexander Jacobson i2x Media
        1-212-787-1914 voice 1-603-288-1280 fax
      • Paul Prescod
        ... I d like (e.g.) to be able to make a resource such that references to that resource result in redirects to another resource on another machine with no
        Message 3 of 11 , Feb 1, 2002
        • 0 Attachment
          "S. Alexander Jacobson" wrote:
          >
          > On Fri, 1 Feb 2002, Paul Prescod wrote:
          > > > Re URI handling, do you mean RFC2192?
          > > The protocol doesn't know anything about RFC2192, does it?
          >
          > Does it need to? What are you trying to
          > accomplish?

          I'd like (e.g.) to be able to make a resource such that references to
          that resource result in redirects to another resource on another machine
          with no coordination between the two machines.

          >...
          > > Don't know what you mean. Can IMAP do content-negotiation so that I can
          > > ask for a particular message in different content-types depending on the
          > > client?
          >
          > That is the purpose of multipart/alternative. See
          > RFC2046 sec. 5.1.4:

          It isn't the same thing. The information producer has to generate all of
          the types speculatively.

          >...
          > I don't think so. Pick an application that works
          > better for HTTP than IMAP.

          Does IMAP even have a notion of non-authorized references that would
          allow me to reference public IMAP servers? Anyhow, I gave you an example
          above.

          >...
          > Nothing stops you from exposing a view of your
          > schema rather than your underlying schema. If you
          > do end up exposing your schema, you can always
          > expose a view later when you change it.

          It typically is not that easy in practice. You really need a rich,
          Turing complete, programmatic layer between outsiders and your databases
          -- much more than a view with some stored procedures. You need to be
          able to unify multiple data sources. So you would have to *implement*
          the ODBC/SQL interface in code.

          Even relational companies do not push ODBC/SQL as a good middle-teir
          integration so I

          > Since there is a pretty direct mapping between
          > resources and objects in table, I am not really
          > sure what you are arguing here.

          That ODBC/SQL is only intended to be an abstraction layer over
          relational databases. Trying to make it a general purpose integration
          layer for (e.g.) structured data and multiple data sources will be
          painful.

          >...
          > The reason why HTTP and SMTP have been so
          > succesful in letting people talk to one another is
          > MIME. No non-MIME transport protocol has been
          > particularly successful.

          I will agree that this is yet another reason why the RPCs will probably
          fail...

          Paul Prescod
        • S. Alexander Jacobson
          ... E.g. someone emails you a web page with an IMAP URL in it. You click on the URL and your browser retrieves the IMAP page? That is the whole purpose of
          Message 4 of 11 , Feb 1, 2002
          • 0 Attachment
            On Fri, 1 Feb 2002, Paul Prescod wrote:
            > > On Fri, 1 Feb 2002, Paul Prescod wrote:
            > > > > Re URI handling, do you mean RFC2192?
            > > > The protocol doesn't know anything about RFC2192, does it?
            > >
            > > Does it need to? What are you trying to
            > > accomplish?
            >
            > I'd like (e.g.) to be able to make a resource such that references to
            > that resource result in redirects to another resource on another machine
            > with no coordination between the two machines.

            E.g. someone emails you a web page with an IMAP
            URL in it. You click on the URL and your browser
            retrieves the IMAP page?

            That is the whole purpose of RFC2192?

            If you mean 30x style redirection, you can return
            a message with a message/external-body pointing to
            some IMAP URL.

            > >...
            > > > Don't know what you mean. Can IMAP do content-negotiation so that I can
            > > > ask for a particular message in different content-types depending on the
            > > > client?
            > >
            > > That is the purpose of multipart/alternative. See
            > > RFC2046 sec. 5.1.4:
            >
            > It isn't the same thing. The information producer has to generate all of
            > the types speculatively.

            You want server negotiation rather than client
            negotiation. The HTTP spec appears to discourage
            server negotiation.

            In practice, the server has only a finite set of
            types and can enumerate them without sending them
            all using the message/external-body.

            If you really want the equivalent of Accept:,
            style content-negotiation, you can implement it
            with Search.

            > >...
            > > I don't think so. Pick an application that works
            > > better for HTTP than IMAP.
            >
            > Does IMAP even have a notion of non-authorized references that would
            > allow me to reference public IMAP servers?

            Yes, it is like anonymous FTP. See e.g.
            http://www.cyrusoft.com/support/faq/anonimap.html

            > > Nothing stops you from exposing a view of your
            > > schema rather than your underlying schema. If you
            > > do end up exposing your schema, you can always
            > > expose a view later when you change it.
            >
            > It typically is not that easy in practice. You really need a rich,
            > Turing complete, programmatic layer between outsiders and your databases
            > -- much more than a view with some stored procedures. You need to be
            > able to unify multiple data sources. So you would have to *implement*
            > the ODBC/SQL interface in code.

            Why? You are just implementing

            SELECT contentType,content FROM resources
            WHERE id='someuri.html'.


            > Even relational companies do not push ODBC/SQL as a good middle-teir
            > integration so I

            Actually, Oracle basically thinks of web apps as a
            think layer on top of stored procedures and
            queries.

            > > Since there is a pretty direct mapping between
            > > resources and objects in table, I am not really
            > > sure what you are arguing here.
            >
            > That ODBC/SQL is only intended to be an abstraction layer over
            > relational databases. Trying to make it a general purpose integration
            > layer for (e.g.) structured data and multiple data sources will be
            > painful.

            So you want an odbc URL. That exists.
            Delivering an odbcURL + SQL tuple seems pretty
            straightforward.

            -Alex-
            ___________________________________________________________________
            S. Alexander Jacobson i2x Media
            1-212-787-1914 voice 1-603-288-1280 fax
          • Paul Prescod
            ... I m scared of the term application because we also build applications on top of HTTP. Plus, RPC has its own set of semantics involving parameters, return
            Message 5 of 11 , Feb 3, 2002
            • 0 Attachment
              Mark Baker wrote:
              >
              >...
              >
              > This is like saying that Ethernet is general purpose. It's true, but
              > not too useful. RPC is a lower layer than HTTP because it defines no
              > application semantics, leaving them for the "API" to define.

              I'm scared of the term "application" because we also build applications
              on top of HTTP. Plus, RPC has its own set of semantics involving
              parameters, return codes, methods, etc. The word semantics is also a
              mine-field. I'm one of a vocal few people who claim that XML has
              semantics (angle-brackets are syntax, attributed-trees are semantics).

              > Linda, like HTTP and FTP and NNTP, defines the methods. So you've
              > got an application layer contract - a coordination language -
              > between endpoints a priori.

              Is SMTP a coordination language? Do we have a definition that can be
              made precise?

              >...
              > > Definitions aside, the point remains: in terms of generality, HTTP has
              > > more in common with SOAP than with SMTP. It is not just about moving
              > > HTML pages from servers to clients.
              >
              > I'd say it's the other way around. SMTP "DATA" has a precise
              > meaning, not unlike POST.

              I know you claim that POST's meaning is precise. ;)

              >...
              > > HTTP is similar. HTTP allows you to read from the storage with GET,
              > > write to it with PUT and the addresses are URIs. Because disk space in
              > > the real world is limited, HTTP also has DELETE. And because multiple
              > > people will be using the system at once, there is a need for a method
              > > that will create guaranteed-new "storage locations".
              >
              > I'd say that POST was the movement of the tape. PUT creates new
              > locations.

              We disagree on the meaning of POST. What a surprise. ;)

              If we are strict about the idea that URIs are opaque then the client
              doing the PUT can't really know what URI to use to create a new
              resource. POST can be used to provide a new URI.

              > > FTP is the closest protocol to HTTP conceptually. But really the gap
              >
              > I think NNTP is probably closest. It has POST (that's where HTTP's
              > POST came from), a basic get (ARTICLE), and a very specific type of
              > put (for setting read messages).

              FTP has a more general GET (i.e. it has a concept of hierarchy and
              filenames) and PUT.

              > > important, though, FTP's semantics do not allow the server to be an
              > > active participant in the computation. HTTP very precisely defines how
              > > the server can do complicated computations by itself. It is not just a
              > > holder of bits -- it can embody a complex service!
              >
              > You mean the app here I guess. You should distinguish between the
              > web server and the web app.

              Okay.

              > > efficiency and modeling simplicity. For instance WebDAV has a LOCK
              > > method which could be modeled as a POST of a LOCk object. In theory the
              >
              > PUT actually, since it is defined absolutely.

              Okay.

              >...
              >
              > > I say "quasi-universal" because there are limits. Just as XML isn't
              > > really great for binary media, HTTP isn't really great for streaming
              > > real-time media. So for those applications you should use something
              > > else.
              >
              > (though perhaps with HTTP's application semantics)

              Okay.

              > > There is no doubt that HTTP has its limitations. For one thing there is
              > > not much software out there that knows how to deal with HTTP in a
              > > peer-to-peer or asychronous fashion.
              >
              > I don't know what that means.

              Define client as a device with potentially transient connectivity,
              directly controlled by an end-user.
              Define server as a device with persistent connectivity not controlled by
              an end-user.

              There is not much software out there that uses HTTP to have servers
              contact clients, or servers to contact servers using HTTP. This is
              important because it means that firewalls are not appropriately
              configured for that sort of usage. Thus, KnowNow single-byte hacks.

              Paul Prescod
            • Mark Baker
              ... Technically, we don t. I know the common use of the term is just that, but in actuality, we are simply adding more resources to an existing app, the Web.
              Message 6 of 11 , Feb 3, 2002
              • 0 Attachment
                > > This is like saying that Ethernet is general purpose. It's true, but
                > > not too useful. RPC is a lower layer than HTTP because it defines no
                > > application semantics, leaving them for the "API" to define.
                >
                > I'm scared of the term "application" because we also build applications
                > on top of HTTP.

                Technically, we don't. I know the common use of the term is just that,
                but in actuality, we are simply adding more resources to an existing
                app, the Web.

                > Plus, RPC has its own set of semantics involving
                > parameters, return codes, methods, etc. The word semantics is also a
                > mine-field. I'm one of a vocal few people who claim that XML has
                > semantics (angle-brackets are syntax, attributed-trees are semantics).

                Sure, and I agree with you about XML having semantics (Jon Bosak has
                said as much). But "application semantics" has a much more precise
                meaning, though not commonly known.

                > > Linda, like HTTP and FTP and NNTP, defines the methods. So you've
                > > got an application layer contract - a coordination language -
                > > between endpoints a priori.
                >
                > Is SMTP a coordination language?

                Yes.

                > Do we have a definition that can be
                > made precise?

                I'm sure we could whip one together without much trouble. As I say on
                the Wiki, I believe that all application protocols are coordination
                languages.

                > We disagree on the meaning of POST. What a surprise. ;)
                >
                > If we are strict about the idea that URIs are opaque then the client
                > doing the PUT can't really know what URI to use to create a new
                > resource. POST can be used to provide a new URI.

                Right, that's the point.

                The whole idea with PUT is that the client specifies the name, likely
                because it had previously done a GET and so knows what the name already
                is. But any container can choose to reject a PUT with a name it doesn't
                like, so that's why it's still opaque (it determines the meaning of
                the name). I suppose that somewhere in there is a PUT based form
                solution where the form suggests a URI.

                POST means "accept as a subordinate", which means that the client is
                specifically punting all responsibility for the document to the
                container, including naming it, as you say.

                > > > FTP is the closest protocol to HTTP conceptually. But really the gap
                > >
                > > I think NNTP is probably closest. It has POST (that's where HTTP's
                > > POST came from), a basic get (ARTICLE), and a very specific type of
                > > put (for setting read messages).
                >
                > FTP has a more general GET (i.e. it has a concept of hierarchy and
                > filenames) and PUT.

                News groups and articles are hierarchically named too. Each group is a
                container that contains multiple articles, articles can be posted to
                multiple groups, etc.. (it goes beyond HTTP here, and gets into
                KnowNow-land with message ids and topics).

                MB
                --
                Mark Baker, Chief Science Officer, Planetfred, Inc.
                Ottawa, Ontario, CANADA. mbaker@...
                http://www.markbaker.ca http://www.planetfred.com
              Your message has been successfully submitted and would be delivered to recipients shortly.