Comments on: Rounded Corners – 138 (Snap!) http://labnotes.org/2007/08/23/rounded-corners-138/ Sun, 15 Jan 2012 21:29:54 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Assaf http://labnotes.org/2007/08/23/rounded-corners-138/comment-page-1/#comment-138328 Assaf Thu, 30 Aug 2007 15:23:37 +0000 http://blog.labnotes.org/2007/08/23/rounded-corners-138/#comment-138328 Tunneling generally means using one protocol through another. Tunneling REST over POST would be: sending a query parameter or some HTTP header to substitute the verb, so the POST behaves as if it was that verb. This is different from just using POST for every state change. SPP works the same way any blog, wiki or flickr does, by using POST for every state change, without even considering the possibility of a DELETE. There's the difference. I personally do not consider the Web to be one big DELETE-over-POST tunnel, so I don't consider SPP to tunnel either. Tunneling generally means using one protocol through another.

Tunneling REST over POST would be: sending a query parameter or some HTTP header to substitute the verb, so the POST behaves as if it was that verb. This is different from just using POST for every state change.

SPP works the same way any blog, wiki or flickr does, by using POST for every state change, without even considering the possibility of a DELETE. There’s the difference. I personally do not consider the Web to be one big DELETE-over-POST tunnel, so I don’t consider SPP to tunnel either.

]]> By: Aristotle http://labnotes.org/2007/08/23/rounded-corners-138/comment-page-1/#comment-138327 Aristotle Thu, 30 Aug 2007 10:25:55 +0000 http://blog.labnotes.org/2007/08/23/rounded-corners-138/#comment-138327 Sorry, what? SPP doesn’t attempt to tunnel over POST…? It’s <em>most definitely</em> tunnelling DELETE. (With PUT, it’s a little fuzzy… but you could consider POST-to-update a tunnelled PUT.) Sorry, what? SPP doesn’t attempt to tunnel over POST…? It’s most definitely tunnelling DELETE. (With PUT, it’s a little fuzzy… but you could consider POST-to-update a tunnelled PUT.)

]]> By: Assaf http://labnotes.org/2007/08/23/rounded-corners-138/comment-page-1/#comment-138297 Assaf Sat, 25 Aug 2007 02:46:56 +0000 http://blog.labnotes.org/2007/08/23/rounded-corners-138/#comment-138297 Tunneling PUT/DELETE over POST is bad, there's no consistent way of doing it, which is why SPP doesn't attempt to. I too hope this will be fixed, but I place my bets on browser technologies like Rails and AJAX and Flash, the ones that use url-encoded and multipart/form-data. I don't see how Atompub will affect Web browsers when it's more of a tool-to-tool protocol. Tunneling PUT/DELETE over POST is bad, there’s no consistent way of doing it, which is why SPP doesn’t attempt to.

I too hope this will be fixed, but I place my bets on browser technologies like Rails and AJAX and Flash, the ones that use url-encoded and multipart/form-data. I don’t see how Atompub will affect Web browsers when it’s more of a tool-to-tool protocol.

]]> By: Aristotle http://labnotes.org/2007/08/23/rounded-corners-138/comment-page-1/#comment-138296 Aristotle Sat, 25 Aug 2007 00:19:36 +0000 http://blog.labnotes.org/2007/08/23/rounded-corners-138/#comment-138296 It ain’t broken, for certain values of broken. Tunnelling PUT and DELETE over POST is <em>pragmatic</em> but not <em>good</em>. I’d rather we had support for PUT and DELETE in the Web browser too (and I mean without relying on Ajax). I dearly hope that Atompub contributes to making that happen. I’d like to think that the web has not ossified quite yet, that it’s still possible to evolve its infrastructure for the better. It ain’t broken, for certain values of broken. Tunnelling PUT and DELETE over POST is pragmatic but not good. I’d rather we had support for PUT and DELETE in the Web browser too (and I mean without relying on Ajax). I dearly hope that Atompub contributes to making that happen. I’d like to think that the web has not ossified quite yet, that it’s still possible to evolve its infrastructure for the better.

]]> By: Assaf http://labnotes.org/2007/08/23/rounded-corners-138/comment-page-1/#comment-138292 Assaf Fri, 24 Aug 2007 15:33:49 +0000 http://blog.labnotes.org/2007/08/23/rounded-corners-138/#comment-138292 Aristotle, the point of SPP is to do the simplest thing that could possibly work and support Web browsers, not win any performance pageants. So it needs to, at the minimum, accept the way in which a browser would upload a picture, and it needs at the minimum let you you send a picture with a title in one post. So multipart/form-data is the way you could do WordPress and Flickr and Tumblr and what have you not, and as evidence the Web keeps ticking and doesn't crumble under its own MIME encoding load. SPP just comes from the position that "this is how the Web works, it ain't broken, why fix it?" Aristotle, the point of SPP is to do the simplest thing that could possibly work and support Web browsers, not win any performance pageants.

So it needs to, at the minimum, accept the way in which a browser would upload a picture, and it needs at the minimum let you you send a picture with a title in one post.

So multipart/form-data is the way you could do WordPress and Flickr and Tumblr and what have you not, and as evidence the Web keeps ticking and doesn’t crumble under its own MIME encoding load.

SPP just comes from the position that “this is how the Web works, it ain’t broken, why fix it?”

]]> By: Aristotle http://labnotes.org/2007/08/23/rounded-corners-138/comment-page-1/#comment-138290 Aristotle Fri, 24 Aug 2007 09:56:13 +0000 http://blog.labnotes.org/2007/08/23/rounded-corners-138/#comment-138290 Actually, you’re wrong. The way Atompub does it, there is no envelope whatsoever. In contrast, <code>curl</code> will generate a MIME envelope behind your back in order to post that, which also requires bloating up the data to 4/3 of its original size. It just looks shorter if you look at the command line because <code>curl</code>’s been optimised for the HTML GET-and-POST web. If you use the LWP utilities instead, then posting an image to an Atompub collection looks like this: <code>< inurprotocolz.jpg POST -c image/jpeg</code> Beat <em>that</em>. Actually, you’re wrong. The way Atompub does it, there is no envelope whatsoever. In contrast, curl will generate a MIME envelope behind your back in order to post that, which also requires bloating up the data to 4/3 of its original size.

It just looks shorter if you look at the command line because curl’s been optimised for the HTML GET-and-POST web. If you use the LWP utilities instead, then posting an image to an Atompub collection looks like this:

< inurprotocolz.jpg POST -c image/jpeg

Beat that.

]]>