lesscode.org

Tantek Çelik: “The namespace problem? The short answer is that it’s nothing more than academic chicken-littling. The internet has worked just fine (at many levels, with many applications, specifications) without namespaces. Namespaces try to solve a 1% problem while burdening the 99%, which is always bad economics.”

I disagree. Namespaces can sometimes be a technical hassle, but I’ve noticed that people who rail against them are usually squatting on a set of short strings. Would it be OK for Microsoft to define the meaning of the word “friend?”

Dan Connolly: “There is a time and a place for just using short strings, but since short strings are scarce resources shared by the global community, fair and open processes should be used to manage them.”

If RSS didn’t restrict extensions to namespaced elements, we would have a very ugly scene on our hands by this time. At what point does technical convenience trump social concerns? In this case, RSS favors a little technical complexity in return for less bureacracy and more fairness. Maybe morecode is occasionally worth it.

Mochikit “is a highly documented and well tested, suite of JavaScript libraries that will help you get shit done, fast. We took all the good ideas we could find from our Python, Objective-C, etc. experience and adapted it to the crazy world of JavaScript. “

If you haven’t listened to Adam Bosworth’s Database Requirements in the Age of Scalable Services, you need to right away. The 45 minute run length seems to be limiting the amount of listenership, which is a real shame because he makes some really great points in the talk.

It’s not really about databases the way you’re thinking it is, it’s about applying the principles that make the web work to the very generic task of exposing, modifying, and querying data. Bosworth is thinking waaaay out of the box here, claiming that RSS and Atom have the potential to do for machine readable data what HTML has done for human readable content. It seems to be an elaboration and progress report on the thinking he demonstrated in his ISCOC04 Talk, which was cited heavily throughout the blogosphere.

But even if you don’t care about databases or Atom/RSS (let’s say you build loan approval or payroll processing applications) you can still get a lot from this talk by simply observing the style of thinking Adam demonstrates. This is exactly what I’m trying to encourage with Motherhood and Apple Pie and I’d like to use Adam’s talk to illustrate the different ways you can think about the web because Bosworth’s talk is a perfect example of The Right Way.

The first way of thinking about the web is to take the design you already have, in this case relational databases, and just put it on internet pipes (i.e. use web protocol as a conduit for what you’re already doing). If Bosworth would have taken this approach he would have been talking about creating an XML representation for SQL queries and tabular data, how to hack in transaction management and isolation levels, and other stuff like that.

As it were, this is not even close to what he talks about and the reason is because that style of thinking does not work.

I’m reminded of Richard Feynman’s excellent Cargo Cult Science:

In the South Seas there is a cargo cult of people. During the war they saw airplanes with lots of good materials, and they want the same thing to happen now. So they’ve arranged to make things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head to headphones and bars of bamboo sticking out like antennas–he’s the controller–and they wait for the airplanes to land. They’re doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn’t work. No airplanes land. So I call these things cargo cult science, because they follow all the apparent precepts and forms of scientific investigation, but they’re missing something essential, because the planes don’t land.

Business IT (as well as major media) are the South Seas islanders of the web. They see the types of things the web is capable of and they try to replicate them using their existing materials, but the planes don’t land. You can observe this happening right now in a vast number of cases including “Web” Services (WS-* specifically), statically typed languages, Active X Controls, Java Applets, XForms, and this website (look closely).

I believe the problem to be two-fold:

1. The great majority of experience with systems was not had with the constraints of the web in place. This makes conclusions drawn from observation of existing working systems, as well as recommendations based on them, extremely unreliable.

2. Very few people are aware of problem number 1 (Adam Bosworth is one them).

It’s interesting that many of the individuals I can think of that understand this situation seemed to have had to learn it the hard way (no offense meant to anyone in this list). Sam Ruby participated heavily in SOAP activity at Apache. Mark Baker’s username is always distobj (Distributed Object) because he was a big CORBA head. Tim Bray had a hand in XML Namespaces and watched, if not participated in, W3C XML Schema. Peter Yared was CTO of Sun Microsystems’ Application Server Division. I worked on XForms (among other things).

Adam Bosworth actually describes this process of being slammed in the face with the realities of the web in his talk:

In 1995 I woke up from a sort-of Microsoft induced narcoleptic coma and realized there was this thing called “The Web,” and got really excited about it.

How did the web happen? People take it for granted. You just assume that there’s always been the web. You know, in the beginning there was the web and the web was good and so on but that actually isn’t true. When Tim Berners-Lee came out with HTTP and HTML it turned out that he kind of hit a perfect storm of efficiency. He made something really simple and because it was really simple, virtually any P-programmer, by which I mean Perl, Python, and PHP, could generate web content. That was a heck of a lot easier than building on those, for example, really cool looking Mono apps that we just saw. Building a really simple form that says “here’s a list of the tasks that you have due today” was something that virtually anyone who could think could put up on the screen.

What I like to suggest to people coming from a more traditional background in IT is that there are systems that evolved under the constraints of the web and their design reflects that. Once you’ve accepted that the previous statement is factual, you are forced to draw one of two possible conclusions:

1. Systems that were designed through observation of the web and/or in adherence to the core principles of the web must be more suitable to the web than those that were not.

2. Systems that were designed through observation of the web and/or in adherence to the core principles of the web must have been designed by monkeys with little understanding of building systems in the first place.

It is these second types that bother me.

UPDATE: I forget to mention that Rams took notes on the talk.

I’ve been on a language and infrastructure kick for the past month or so and posts have reflected that. Unfortunately this means I haven’t had the time to report on some of the excellent discussion around simplifying practices at the protocol and format level. Let’s run through some of this real quick:

Sam Ruby has been churning out good content on the practical benefits of HTTP and REST architecture, challenging SOAP/WS-* practioners to consider the immense benefits resource oriented design offers over the more popular service oriented (SOAP/WS-*) approaches. The Atom Wiki was slashdotted but he was able to push the troll-hoards over to an uneditable site due to HTTP’s redirect capabilities. He uses the occasion to illustrate one of the many basic features HTTP provides to accomodate massively distributed and un-coordinated environments that SOAP/WS-* completely ignores:

The foundation for most of this is rooted in the tantalizing phrase “hypermedia as the engine of application state”. If one views a wiki as a state machine, then being able to do a redirect is effectively changing the programming of the application.

The fact that I was able to do all this with but a single line of code — and using only the protocols and products that were already installed — was of great value to me yesterday. In fact, if one were predisposed to use such terms, I would go so far as to say it was of significant business value to me.

Sam provides more thoughts and conclussions in REST vs. API, which he sums up nicely:

At some point, you need to question the wisdom of having an API which abstracts away that which is important.

In the meantime, WS-* supporters are still trying to figure out how to fit the square peg of narrowly distributed systems architecture into the round hole of the web. Infoworld just published a story that tries really hard to slap some lipstick on the WS-pig:

Although the vendors backing Web services are confident they are properly addressing any kinks, Web services remains hobbled by issues such as standardization and WSDL complexity. To make matter worse, its impacts are growing, with both the .Net and Java development technologies focusing on Web services. Additionally, Web services is doing double duty as the lynchpin of the growing SOA trend.

And just in case there was any doubt that many leading vendors are completely clueless when it comes to providing tools to aid their customer’s operations moving to the web:

Microsoft’s Bixhorn emphasized the company’s planned Indigo technology as the answer to many issues cited with Web services. Due in 2006 in the Windows Longhorn client, Indigo removes the reliance on Web servers by extending beyond HTTP to support protocols such as SMTP, TCP, and REST (Representational State Transfer).

No, no, no! I don’t even know where to begin disecting the problems with this statement.

1. You don’t want to “remove the reliance on web servers,” you want to provide tools that let customers use it for what it’s worth. Web servers are good! We need to make more and better use of them.

2. Extending HTTP to “support REST” would be a truly interesting demonstration as REST is largely a description of the architecture HTTP facilities. UPDATE: it’s been pointed out that I may have mis-represented Krill’s intent here. I’m not sure I see a huge difference but in the interest of rational debate and all that…

3. <outrage>TCP?!!@%##! WHAT THE FUCK!</outrage>

I can only assume this was a horrible misprint or that Microsoft has an automated press statement request robot capable of combining a random set of acronyms with upcoming product names.

The blogosphere, at least, is injecting some sanity into the discussion. Mark Baker wrote a nice piece, Towards truly document oriented Web services, which does a good job of explaining why the web’s basic architecture has been and continues to be a perfect medium for “Web services” since long before the term was even coined.

There were also at least two enlightening articles on Atom’s potential as a SOAP/WS-* competitor. Bill de hÓra’s Atoms in a small world is a response to a computer weekly article making the following claim:

It is clear that there are lots of server-based applications (not blogs) that could work by syndicating packets of XML data to client applications (not RSS aggregators). These will not rival Soap/web services as a system for executing transactions.

Bill responds:

I don’t see why it would not be a good basis for enterprise concerns like messaging, authentication, or management interfaces. Atom, RSS and the Atom Publishing Protocol (APP) as a complement to REST could disrupt SOAP and WS.

I agree but have a slightly different take on how this will be most disruptive. In my opinion, REST and web architecture is just plain misunderstood. There’s a lightbulb moment that’s required to grasp it fully and it just hasn’t went off for a big portion of the business IT community. RSS and Atom are showing how following web architecture can yield huge benefits. These technologies are disruptive because it forces people to ponder whether the web in its basic, unmolested form may not be limited to web pages. If Atom can find a niche here than that’s great but I’m more excited by its potential as an agent for enlightenment.

Kurt Cagle follows Bill’s post with some truly excellent examples of how, in many cases, RSS/Atom can be superior to WS-* techniques in How RSS/Atom Is Replacing Web Services, which he ends with a demonstration of “good web thinking”:

While I suspect that this commentary will be poo-pooed by web services vendors, the history of the web makes me suspect I’ll be right in the end. RSS syndication has emerged in a largely ad-hoc fashion to fulfill a specific need - syndication - that seems to be an intrinsic characteristic and requirement of the Internet. Syndication in turn is simply a messaging protocol built around a subscription-oriented PUSH model. If you make the syndication format too complex for people to use (as I believe is the case with SOAP) then they will migrate to simpler formats as they become available. Because ATOM is blessed by both the IETF and the W3C and is seen as an open standard (whereas questions remain concerning the precise nature and implementation of SOAP) it will likely continue to gain the mindshare of developers and users alike.

To sum up, there’s been good stuff all around from the REST / web architecture guys and the WS-* death march continues on…

If everything works out properly, we should be seeing more of these kinds of organizations:

Portland Open Source Software Entrepreneurs (POSSE) is a local organization of entrepreneurs who rely on and develop OSS to help businesses succeed.

POSSE provides local businesses with access to a wealth of qualified options for meeting their open source software needs. All POSSE members are established companies that adhere to a defined set of industry best practices.

I touched on it a bit in Motherhood and I’ll be talking about it more - the industry is going to start widening way out. We’ll see thousands of small crews providing very targeted services. Screw infrastructure, long live the app - you build a new one each month. We’ll build the infrastructure collaboratively.

A basic level of interoperability with other crews’ stuff will come as a result of adherence to core design principles… Arrgghh, there’s so much to talk about here.