Re: Reliable HTTP

(oops, sent from the wrong email address)

Mark Nottingham wrote:
> 
> Hi John,
> 
> Generally, I question the choice of HTTP as a base for reliable
> messaging. You seem to spend a fair amount of effort avoiding HTTP
> mechanisms (by defining a separate set of headers, your own chunking
> mechanism, etc.), while not really getting too many benefits from it.
> BEEP seems like a much more natural choice in this respect.
> 
> HTTPR seems to define a protocol-as-a-content-type that's designed
> only to be useful in the context of HTTP. This sets a confusing
> stage, to say the least; there are several points in the document
> where I'm not sure if you're talking about HTTP messages, HTTPR
> messages or payload (e.g., SOAP) messages.

I couldn't agree more with Mark, except for perhaps - in part - that
first sentence.  I do  believe it's quite possible to extend HTTP to
support reliable *hypertext transfer*.

> I'd think that serious consideration should be given to other options
> first (in rough order of prefernce):
> 
> 1) define a BEEP reliable messaging profile
> 2) define a SOAP reliable messaging module
> 3) define HTTP extensions (methods, headers and status codes) for reliable
>    messaging

#3 is pretty key if they want to use HTTP, and HTTPR doesn't currently
make very good use of HTTP's extension mechanisms.  For example, the
HTTPR "request" header appears to modify the semantics of HTTP POST so
much in some cases, that a new HTTP method should be created or an
existing one reused (GET comes to mind for get-requester-info).  In
fact, "request" appears to be nothing more than a means of encoding an
RPC style method invocation mechanism over HTTP POST.  This doesn't fit
well with the hypertext transfer application semantics that HTTP
defines.

MB

Received on Monday, 16 July 2001 20:19:13 UTC