[
Lists Home |
Date Index |
Thread Index
]
On Monday 10 February 2003 18:21, Mark Baker wrote:
> On Mon, Feb 10, 2003 at 04:40:01PM +0000, Alaric B. Snell wrote:
> > And on top of that sat the actual application protocols; the SEs are not
> > protocols themselves, they are more like protocol toolkits. More like the
> > convention in most IETF protocols of single line commands and three-digit
> > response codes, found within SMTP and POP3 and others. But they allow the
> > actual applications to be built on top of something higher-level than raw
> > TCP or UDP!
>
> Right, I follow. I suggest that there's not a whole lot of value to
> that model, since two parties over the Internet need to agree on
> an application protocol in order to get anything done without a priori
> agreement; how that protocol was was designed, or what its constituent
> SEs may be, is irrelevant.
To the end user, yes, but not to the application developer.
Point of terminology: HTTP was designed as an application protocol, "what web
browsers speak to web servers", just as SMTP is for email etc.
However, if you use HTTP to base lots of different applications on top of -
so your mail client uses HTTP to talk to the mail server, etc - then it
becomes a service element of those protocols, really. This is particularly
obvious if you run it over a port other than 80!
(I *hope* I'm using the term 'service element' correctly; I wasn't around at
the time it was coined...)
Now, the value of HTTP as a service element is that you could put two
different applications on top of it, to support the same goal. Say we use
HTTP to replace IMAP with a design based around visiting the URL of the
mailbox *plus the prefix "/mail.xml"* to get an XML document of the form:
<mail-account name="alaric@alaric-snell.com" fullname="Alaric Snell">
<folder name="Inbox" uri="http://mail.alaric-snell.com/alaric/INBOX"; />
<folder name="Archives">
<folder name="XML-DEV"
uri="http://mail.alaric-snell.com/alaric/Archives/XML-DEV"; />
<folder name="ASN.1-DEV"
uri="http://mail.alaric-snell.com/alaric/Archives/ASN.1-DEV"; />
</folder>
</mail-account>
And that the mailbox URIs, with appropriate query parameters, can be used to
get messages by ID or to query for message IDs matching a criteria, and there
are POSTs that can be done to move and delete messages, etc.
However, at the same time, we can say that implementations should, if queried
on the mailbox URI itself (without the "/mail.xml" prefix) present some HTML
forms-based interface for people without special clients.
In this usage, we're taking the mechanism of HTTP and abstracting it away
from hypertext transfer, into a service element which we might call 'Bob' or
something. Then HTTP proper is that service element used to transfer
multimedia to a Web browser; that is the application. Now that we run HTTP
over 'Bob' and email over 'Bob', we can arrange it so that things fit
together in ways that allow more than one protocol interface to a given
resource.
Note that 'Bob' still defines GET and POST and so on; don't worry, I'm not
trying to disturb your RESTful sleep in this thread :-) But GET and POST
alone do not an application protocol make.
> MB
ABS
--
A city is like a large, complex, rabbit
- ARP
|
