Entries classified under weblog created during Mar 2005

I'm catching up on the happenings of PyCon and thought this IronPython keynote summary was interesting:

The news from this morning's keynote is: IronPython released (at last). The running joke in Jim Hugunin's talk was pretending that it had only been two months since he joined Microsoft. In fact, it took about eight months to work out how to do an open source release once he got to Microsoft.

That's not funny - it's a miracle.

The new plan is to release every two weeks until there is a 1.0 release. There are one-and-a-half engineers working on IronPython. Jim is spending half his time evangelizing dynamic languages and Python within Microsoft. The hope is that the next version of CLR will have better support for dynamic languages.

I started ranting here about how quality dynamic language support on the VM is coming down to a battle of who will get lucky and be the less clueless between Microsoft and Sun. The more I think about it though, the less I care. Here's why:

• Small teams are good teams. Nine women can't make a baby in a month and all that... I'd rather have Jim-and-a-half take two years writing a quality Python implementation on the CLR than to have an, uhh, more traditional Microsoft product in six months.

• Maybe Patrick is right. Actually, I'm sure he's right; I just haven't decided if that means there's no value running dynamic languages on the VM. I think we need something to break through on one of the VMs if we're ever going to move this into the enterprise. There's no way I could bring Python into my place of business on any serious level. This really comes down to it not being blessed as Enterprise Class (blech!) by Sun. It seems we need the VM to get in the door and then maybe we can just move quietly toward CPython with a Java/CLR bridge?

Patrick Logan wonders what I'm referring to when I use the word success in this paragraph from What WS-* Got Wrong:

From the beginning, WS-* has been approached incorrectly. The approach that we're advocating is to first embrace and understand existing web architecture and then to gradually enhance (constrain) it to meet the needs of new requirements. We advocate this not because we think it's a better way to be successful, we think it's the only way to be successful.

That's some claim! Is "success" even defined in this case? -Patrick

Success is the widespread adoption of some form of interoperable communications between coordinated and uncoordinated machine agents over large network bodies.

What I was trying to say here is that my beef with WS-* has less to do with architectural and technical issues and more to do with pragmatism and practicality. I'm fully aware that these technologies could be adopted and would work more or less as specified. My problem is that WS-* won't be adopted in any significant way because it does not exhibit the traits necessary for a technology to be adopted on a large scale.

If someone personally coordinated 200 people in various organizations, I'm sure they could implement solutions on top of WS-* given a long enough time-frame. If 200 people are working separately, and are left to their own devices, in a more organic, web-like environment, WS-* has much less chance of being used successfully.

I see REST vs WS-* as a simple case of worse is better (except in many ways I think REST is the more technically correct so bonus points there). It does exhibit the traits required for technology to be widely adopted and what's more, it already has been widely adopted.

Mark Baker brings up an important aspect of the WS-* vs. REST situation that I've been hoping to speak about myself:

Yes, absolutey, we'll need the capabilities that the WS-* stack provides (for the most part). But do we need the WS-* stack itself to provide those capabilities? I'm certainly all for trying to reuse existing specs where that makes sense. The issue though, is that with most of them, they explicitly or implicitly require disregarding a key constraints of REST, disrespecting Web architecture, or both. WSDL's probably the poster child for this, as its raison d'etre is primarily to encourage rejection of REST's uniform interface.

Right. The problem with WS-* isn't that its trying to solve the wrong problems or that nothing valuable has been produced. The problem is the general disregard for existing web architecture. WS-* tried to take a revolutionary approach to something that required only incremental improvement. HTTP and URIs were treated as legacy technology that would provide a quick and dirty mechanism for bootstrapping this special next generation of web technology.

The REST advocates' criticism of WS-* generally comes off as an attack on technology or architecture but what really pisses the REST people off is the WS-* approach. From the beginning, WS-* has been approached incorrectly. The approach that we're advocating is to first embrace and understand existing web architecture and then to gradually enhance (constrain) it to meet the needs of new requirements. We advocate this not because we think it's a better way to be successful, we think it's the only way to be successful.

An example of the approach we're advocating is Bill de hÓra's recent proposal for reliable messaging over HTTP, (HTTPLR). The difference between the HTTPLR approach and the WS-ReliableMessaging approach is that Bill's proposal builds on simple proven web architecture without requiring additional apparatus.

Anyway, what we need to learn from this is that most successful technologies aren't successful on accident. HTTP and URIs were generally understood only at a very technical / bits-on-the-wire level -- the RFCs existed but Roy Fielding's architectural description came much later and I think it hurt us. We didn't understand how HTTP and URIs formed an overall architecture and how vital that architecture was to the success of the web. If the larger technical community had had an architectural understanding of the web, we might not be in such a mess.

What many of us are now wondering (and have been wondering for some time) is how much longer WS-* is going to continue down a path of incompatibility with web architecture and whether the work that's in progress or that has been completed by WS-* can be reconciled to work under the constraints of web architecture. The feeling I get is that a lot of the REST advocates feel so spited from years of being ignored that they would rather sit back and watch the WS-Building burn to the ground and build from scratch, which is unfortunate for everyone really.

Technorati is no longer using del.icio.us for their tag search and is now only pulling tag information from furl (I'd give a link to the announcement but I don't think it's been announced yet.. Or it may not be.) The members of the delicious-discuss mailing list (including myself) made the obvious assumption that Technorati was choosing sides in bookmarking/tag space:

But it may be of interest to this group that they seem to no longer be pulling links from Del.icio.us, but now only Furl.

I have my own opinions on this, but...Joshua, care to comment publicly on this?

Ahhh, but the reasons are not as they seem. Joshua responds:

I cut them off when delicious was having severe load issues (they cause a query that's almost always uncached due to the queries being random stuff someone types into a field) and they must have turned it off at some point.

-j

Ha! Joshua is, as far as I know, the sole proprieter of one of the most exciting pieces of web technology right now. Lucky bastard. Except it's not luck at all. It's being able to think simpler, more specific, more targeted, more constrained, more obvious, and more useful than everyone else. Less is more.. Less is more.. Less is more..

I think Jonathon Schwartz (President/COO, Sun Microsystems) just joined the loyal WS opposition:

5. Web services may collapse under its own weight.

No one at the conference said this. Those are my words. I'm beginning to feel that all the disparate web service specs and fragmented standards activities are way out of control. Want proof? Ask one of your IT folks to define web services. Ask two others. They won't match. We asked folks around the room - it was pretty grim. It's either got to be simplified, or radically rethought.

As you know, I also believe simplicity and volume always win - and that today's web services initiatives are in danger of vastly overcomplicating a very simple (really simple) solution.

What's been apparent to those in the trenches for the past year or two is finally starting to find its way up the chain of command.

Kid 0.6 is available.

This is a feature release with some pretty important enhancements including Template Inheritence, Match Templates (kind of like XSLT's), cElementTree support, and a refined Python API. Quite a bit of time was spent on the documentation as well.

The Release Notes have more information on everything that has changed.

Kid is an XML based template language for Python that merges the best of Zope's TAL, PHP, and XSLT into a single coherent package. It was created to provide a simple method of generating dynamic, well-formed XML documents using familiar concepts from popular text templating languages.

Download

http://lesscode.org/dist/kid/

Release Notes

http://lesscode.org/doc/kid/0.6/notes.html

Project Information

http://lesscode.org/projects/kid/

Could someone in the Cinci area with a blunt object stop over at Clint's and help him Kill Himself. He's witnessed the new and improved, shiny, senseless, stupid, Netscape 8.0 User Interface.

So here's the story as I understand it. Netscape/AOL took Firefox and rebranded it, which was expected. What wasn't expected was that they completely reverse every single usability refinement the Firefox developers have been working on over the past two years. This is just completely crazy. I'm all shock and awe over here.

I might have expected this around 2000, when shiny was all that mattered but we've grown since then. The whole premise behind Firefox was to cut away the fat and shiny stuff that grew on the Mozilla base over years of being controlled by a clueless marketing department. How is it that this was completely lost on the AOL/Netscape folks?

People don't want more, they want less.

Anyway, this one is going down in net history so I had to get a mention in for the archives.

So there's buzz around some new quasi-Open Source MQSeries¹ clone named AMQ. Supposedly, this thing is going to be used for Web Services and Service Oriented Architectures (SOA) in the financial industry initially but then grow horizontally. The idea being that message queuing provides a lot of the functionality not directly handed to you by HTTP, like reliable delivery, publish/subscribe, multiple subscribers, etc.

The article was kind of weird though because some of it doesn't make any sense:

Not only has AMQ drawn the participation of several banks, but also companies such as Red Hat Inc., Novell Inc. and Sun Microsystems Inc. are considering building AMQ into the kernels of Red Hat Enterprise Linux, SuSE Linux and Solaris, respectively, Davies said.

Wtf? No one is building message queuing functionality into the kernel, bro. That's user-land stuff.

Although Davies said he is an avowed Java aficionado and a supporter of the Java Message Service API, he said JMS "fails on the non-Java side as a transport mechanism."

That's like saying JDBC sucks at indexing my tables. JMS is a standard Java interface that various message queuing implementations implement so that coders don't have to write to vendor specific APIs. There's no transport mechanism involved. If AMQ is truly a MQSeries clone, it will have a JMS implementation wrapped around it within a month. Maybe the original intent was to say that no existing F/OSS MQ implementations have open wire formats? Or something?

I think what this article may have actually been trying to say (although we may never know because it is so full of hallow buzzwords) is something like the following:

1. We, the financial industry, hate proprietary shit.

2. We are tired of waiting around for you WS and SOA folks to actually produce something we can use.

3. We just want a non-proprietary MQSeries that we can use over the internet.

4. There are no open protocols for message queuing and, like we said, we need message queuing. Don't even start with that abstracting non-functional concerns crap. We need message queuing, period.

5. We have developed an open protocol for message queuing. We've done this, somewhat mysteriously, behind closed doors.

6. We've implemented this open protocol in C and C++ and we're going to make these implementations available under some kind of open license.

7. We're going to call this Web Services and SOA because that's what my boss' boss said he wanted and since none of you people can tell me what any of this stuff is, I don't think you can say it's not what we've built.

It seems reasonable to believe that all we're looking at here is an internet friendly protocol and app for chucking messages around in a secure manner which, to be honest, is probably all that's needed. Except it seems to be having an identity crises because it's talking about Web Services and we all know by now that Web = HTTP/URIs and AMQ will likely use neither.

REST is already eating one half of the WS-Sandwich on the web with WS-* retreating to Enterprise Level tasks. I don't think it's impossible to imagine a not-to-distant future where ad-hoc message formats pop up and start flying over this AMQ thing to eventually eat the other half of the WS-Sandwich.

WS-Crust anyone?

Footnotes

^1. I don't care that they rebranded it WebSphere MQ. It's MQSeries... Shut-up.

Yahoo! launched a Web Services interface today. I'm gushing with joy over their decision to follow proven web architecture and select a simple REST model over a more complex WS-* model. Let's take a look at an item pulled from their FAQ:

Q: Does Yahoo! plan to support SOAP?

Not at this time. We may provide SOAP interfaces in the future, if there is significant demand. We believe REST has a lower barrier to entry, is easier to use than SOAP, and is entirely sufficient for these services.

Get used to that answer. You won't ever hear it from the evil tool vendors but you can be damn sure you'll be hearing it from the smart service providers that really are looking to court developers.

Also, it was extremely cool to serendipitously stumble across mine own How I explained REST to my wife article after passing from Yahoo!'s Constructing REST Requests page to Wikipedia's REST page.