I did it, I converted from the blagg/ blosxom combo to Bloglines yesterday. A tiny awk script converted my blog list to OPML, and that was that. So far, so good, though Firefox seems to crash when the list of entries gets large.
I also wish that browsing the entries didn’t automatically mark them as all-read (side-effects on GET = bad!); a simple “done” button would be far better, I think.
I made my subscriptions public.
Here’s a neat idea from Mike about how to bridge the divide between WS/SOA advocates, and Web folks;
What I’d really like to see here is the application of a well-known conflict management technique in which each side has to state the other side’s position, to the other’s satisfaction, before discussing the disagreement.
and;
So, why don’t the Web standards suffice for computer/computer interactions? People have been talking past each other on this topic for years now. How about it? Maybe Mark Baker could re-state his understanding of why Don Box thinks they don’t … and vice versa … before wrapping this permathread around the blogosphere one more time.
Hang on there … I thought my task was to attempt to state Don’s position, no? You seem to have done an adequate job at that when you stated “Don Box thinks they don’t suffice”, which I agree with. Though I could probably take a stab at explaining why Don believes this, it would really just be conjecture, and doesn’t seem to be required of me by this process.
And just to clarify, I don’t think “sufficiency” is necessarily the right test; on occasion, even me – yes, yours truly, the REST fanatic – has used non-uniform semantics. I just happen to think that uniform semantics suffice for, oh, say, 97% of stuff you might need to do when integrating applications over the Internet using document based messaging. “uniform” is the ultimate in generality, after all.
Well, those new specs sure got a thorough thrashing, although perhaps indirectly. Tim Bray and Sean Mcgrath sum it all up for me, as usual.
<html xsl:version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns="http://www.w3.org/TR/xhtml1/strict">
<head>
<title>Expense Report Summary</title>
</head>
<body>
<p>Total Amount: <xsl:value-of select="expense-report/total"/></p>
</body>
</html>
Update; ok, for the two of you that missed my point, that document is both an XHTML document and an XSLT 1.0 stylesheet. All the root namespace tells you is, well, the root namespace. The actual type is orthogonal to this, and in fact, orthogonal to anything in the document itself. Unless we want to prevent this form of compound document from being used, it is critical that media types continue be the key from which applications are dispatched.
As previously suspected, it seems WS-Transfer is missing POST because of an attempt to limit it to CRUD semantics. From the latest MS whitepaper;
A factory is a Web service that can create a resource from its XML representation. WS-Transfer introduces operations that create, update, retrieve and delete resources.
That’s one possible interpretation, arguably reinforced by Don’s post.
Feel the love!
It’s been a long time coming, but the Web services stack finally catches up to where the Web was 15 years ago, and where email was 20 years before that; exchanging documents over the Internet. Happy days! <groan/>
Facetiousness aside though, it’s unfortunate that the layering is still so butchered; WS-Transfer just reinvents HTTP on top of SOAP on top of HTTP. And for what exactly? They could have just reused HTTP’s methods which are already outside the envelope, the way most people use application protocols, and still get all the goodness of SOAP. Who the heck wants to try to bootstrap a whole new Web when the one we’ve got is doing just fine, thank-you-very-much?
It’s also curious that POST is missing, yet CREATE has been added. This seems an obvious attempt to equate the uniform interface with CRUD, but it’s unclear whether that’s to try to restrict the range of possible applications WS-Transfer could be used for, or because the authors honestly thought nothing was being lost with this omission? Knowing many of the authors, I bet the latter, but who knows …
As interesting as this is to see though, I don’t see anybody choosing to use it over vanilla HTTP or RESTful SOAP+HTTP. I’d be interested in anybody’s thoughts who disagreed with me on that.