From the it-just-keeps-getting-wackier file, this;

The goal of XDI is to do for controlled data sharing what the Web did for open content sharing

Wow, where to start on this one?

So, how do “content” and “data” differ exactly? Can the same data not be returned from an HTTP GET on a URI as from an XDI GET on an XRI? And meanwhile, it’s doing the same thing that HTTP does two layers up from HTTP (presumably because of protocol independence reasons), yet is itself a system which is dependent upon the XDI protocol (which unapologetically copies the bulk of HTTP application semantics). Yet another case of those who don’t understand the Web, trying to reinvent it I suppose. Stop the insanity!

Chris responds to an earlier comment of mine.

My point remains that HTTP is not suited to extension of its methods because it requires centralized administration of the method names. You can’t simply make up a new method like MONITOR and deploy it unless you go through the IETF to revise the HTTP specification. Unless you do, then there’s no way that anyone could tell the difference between Mark’s MONITOR method and mine (should I devise one) and yet they might be very different animals.

His point about decentralized method definition is very well taken; HTTP does not permit method names to be URIs. PEP attempted to remedy this, but was never deployed.

But in order to use MONITOR, the HTTP spec doesn’t need revision. There are a multitude of HTTP extensions which are defined as standalone extensions which required no revision of HTTP itself. Consider WebDAV. And as Dave Orchard noted, HTTP is rife with extensibility points; this is no accident, because HTTP was explicitly designed to be extended. Which brings us to this comment;

HTTP wasn’t designed to support pubsub. Just because some sharp people can take the protocol and tweak it here and there to enable pubsub doesn’t change that fact.

HTTP was not designed to support pub/sub, but so? Was SOAP? Nope. But that doesn’t prevent one from using it that way. What’s important is that it wasn’t designed in such a way that prevented (even by being merely a “poor fit”) its use for pub/sub, and IMO, neither HTTP nor SOAP were. HTTP was designed for document transfer, and pub/sub fits there perfectly.

Chris then asks a very good mod_pubsub question;

However, all that aside, I am curious about something else related to mod_pubsub. Sure, it makes use of HTTP GET as well as POST, but are GET and POST really the methods? I mean really… how is this any different than the way in which SOAP uses HTTP POST? do_method?

This is largely what I was referring to when I said “well, parts sure are, but the bulk of it?” in reference to mod_pubsub and hackery. The client portion of mod_pubsub – the Javascript Web server and library – had to resort to lowest common denominator; AIUI, they couldn’t present access to HTTP internals to developers. AFAIK, that’s why “route” is a parameter rather than a new method. It’s actually semantically quite close to WebDAV’s COPY method, both in that it is essentially a copy action, but also that it’s an “interaction at a distance”, i.e. that two URIs are used as arguments, rather than just one which would have required the data being routed to flow to the client. But doing this RESTfully, I could easily imagine a ROUTE method.

This is different to a typical Web services approach (I won’t say “SOAP approach”, because SOAP can be used in so many ways), due to two reasons IMO; first, the semantics being tunneled are uniform, and second, they’re tunneled because there was no other way to do it. In my observation, Web services developers use tunneling primarily because they don’t know how to solve their problems without tunneling, and because they’ve been lead to believe that “protocol independence” is a feature rather than a bug.

Mark talks about document persistence and message transience. I would have agreed with that a few years ago, but as I’ve come to understand the value in self-description, I see that it is possible to have messages persist in meaning for as long as the documents which they encapsulate. A RESTful message is purely self-descriptive, while “SOA” messages are not (they don’t use a constrained interface, nor are they necessarily stateless), so perhaps that’s where the different view point comes from. But I think that persistent messages is an absolute requirement in the asynchronous future we all want to get too, because if you’re doing asynch – which is, of course, “without a clock” – then your message should mean the same thing whether it arrives now or ten years from now.