1. Aug 23rd, 2007

    Rounded Corners - 138 (Snap!)

    The case against OpenID. This is quite an extensive list of problems with OpenID. Some not that bad, and the list was compiled by a vendor, but even with a mountain of salt and turning a blind eye on some parts, I’m left with the impression that OpenID is an ideal in denial of real life lessons. (Via Engtech)

    I’m actually having fun implementing OpenID for a behind-the-firewall app, and although I have no clue what IssuesDone does, I appreciate the simple UI. But out there on the Web … is OpenID something we need to fix?

    The network is the … oh, whatever! As InfoWorld reports:

    Initial reactions to Sun’s ticker change were mostly unfavorable — “a terrible idea,” “a waste of money,” “a stupid move,” “a joke,” and “worst idea ever,” according to most of the comments appended to Schwartz’s blog. Commentators saw the Java ticker as limiting, not expressive of Sun’s overall product portfolio and also very much yesterday’s technology. While Java has been widely adopted, its ubiquity and its 12 years in the market add up to a dated technology, they wrote.

    So how well is Java doing? YTD, struggling to scale up. Must be some tough competition from another four-letter word.

    GigaOm has more fun with corporate restocking strategies:

    4. AT&T (T) to (IFON) because we all know what is juicing their market share and revenues.

    5. Yahoo (YHOO) to (NOGO), which is short for Not Google. You could also take it literally.

    Simply curly. Aristotle, not so impressed with Simple Publishing Protocol, though, ironically proves the point by losing all the markup in the first comment, poses a challenge:

    Or how about uploading a picture:

    curl -H 'Content-Type: image/jpeg' --data-binary @inurprotocolz.jpg https://labotes.org/publish

    That’s actually shorter! Errm, oops, I forgot SPP can’t even do that. :-)

    I have to admit, scared me for a second. But a brief man curl came up with:

    curl -F ‘content=@inurprotocolz.jpg;type=image/jpg’

    So slightly shorter and still no envelopes wasted.

    Presenting presenters. I think it’s a step in the right direction, and I for one welcome our presenters overlords.

    Deezer rocks. Having fun listening to my play list over the Web.

    Pet animal rubber bands. Arcane but cute.

    Posted by Assaf Filed in general

    1. Aug 24th, 2007

      Aristotle

      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.

    2. Aug 24th, 2007

      Assaf

      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?”

    3. Aug 24th, 2007

      Aristotle

      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.

    4. Aug 24th, 2007

      Assaf

      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.

    5. Aug 30th, 2007

      Aristotle

      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.)

    6. Aug 30th, 2007

      Assaf

      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.

    Your comment, here ⇓

    Or using OpenID