{"id":273,"date":"2004-02-09T06:31:00","date_gmt":"2004-02-09T10:31:00","guid":{"rendered":"http:\/\/www.markbaker.ca\/wp\/?p=283"},"modified":"2004-02-09T06:31:00","modified_gmt":"2004-02-09T10:31:00","slug":"mod_pubsub-and-hackery","status":"publish","type":"post","link":"http:\/\/www.markbaker.ca\/blog\/2004\/02\/mod_pubsub-and-hackery\/","title":{"rendered":"mod_pubsub and hackery"},"content":{"rendered":"

Chris responds<\/a> to an earlier\ncomment of mine<\/a>.<\/p>\n\n

\nMy 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.\n<\/blockquote>\n\n

His point about decentralized method definition is very well taken; HTTP\ndoes not permit method names to be URIs.\nPEP<\/a>\nattempted to\nremedy this<\/a>,\nbut was never deployed.<\/p>\n\n

But in order to use MONITOR, the HTTP spec doesn’t need revision. There\nare a multitude of HTTP extensions which are defined as standalone extensions\nwhich required no revision of HTTP itself. Consider\nWebDAV<\/a>. And as Dave Orchard\nnoted<\/a>,\nHTTP is rife with extensibility points; this is no accident, because HTTP was\nexplicitly designed to be extended. Which brings us to this comment;<\/p>\n\n

\nHTTP wasn’t designed to support pubsub. Just because some sharp\npeople can take the protocol and tweak it here and there to enable pubsub doesn’t change that fact.\n<\/blockquote>\n\n

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

Chris then asks a very good mod_pubsub question;<\/p>\n\n

\nHowever, 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?\n<\/blockquote>\n\n

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

This is different to a typical Web services approach (I won’t say “SOAP approach”, because\nSOAP can be used in so many ways), due to two reasons IMO; first, the semantics being tunneled\nare uniform, and second, they’re tunneled because there was no other way to do it.\nIn my observation, Web services developers use tunneling primarily because they don’t know\nhow to solve their problems without tunneling, and because they’ve been lead to believe\nthat “protocol independence” is a feature rather than a bug.<\/p>","protected":false},"excerpt":{"rendered":"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 […]","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[26],"class_list":["post-273","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-soap"],"_links":{"self":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/273","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/comments?post=273"}],"version-history":[{"count":0,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/273\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/media?parent=273"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/categories?post=273"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/tags?post=273"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}