DWR Blogs

Defining The Open Web

Wed, 23 Jul 2008 11:00:41 GMT

Brad asked what the 'Open Web' is. Twice. My mum was always cross if she had to ask 3 times, so here's my stab.

The Open Web is the user-remixable technologies that are shipped by the clear majority of major browsers

So, for example:

XHTML 2.0 is not part of the open web because the browsers didn't go for it even though the W3C did.
XMLHttpRequest is part of the open web even though the W3C haven't gone for it (yet) because it's in all the browsers.
Canvas is part of the open web since it's in everything except IE these days.
XUL is not part of the open web and wouldn't be even if Opera supported it, but if Opera and Safari did, then it would.

Some rationale might be needed:

'User-Remixable Technologies'

One of the key things about the web is how anyone can take part. It's easy for technologists to dismiss what 'normal people' want to do. But cutting and pasting the HTML to embed a YouTube video into your profile is within reach of many people. Maybe not your grandma, but certainly most school leavers.

Are there any significant parts of current browsers that are not user-remixable? Maybe this is built into the ecosystem enough that it doesn't need stating?

'Shipped'

I considered 'endorsed/implemented/supported', but I think the vote comes when it's included in a download.

'Clear Majority'

I don't think we need to be totally unanimous. Indeed requiring unanimity implies a simple lowest common denominator approach. Maybe you could argue for a 75% majority or something. I just went with something simple for now. The implication is that 3 out of the 4 must agree. But that requires me to justify the 4 ...

'Major browsers'

I'd venture to suggest that today there are 4 major rendering engines Trident, Gecko, WebKit and Presto/Core 2. Sorry to Amaya, Lynx and WGet. This isn't a fixed list - if the Java HTMLEditorKit suddenly becomes useful as a browser and widely used, we should pick our jaws off the floor, and include it in the list.

No W3C

Some people would like to make the W3C king and have all innovation be standards lead. But I don't think that history has shown that to be a successful strategy. Some people think the W3C is totally irrelevant, but it is a place where the browser vendors 'sit down' together (by which I mean argue over email). I thought about saying 'major browsers and the W3C' but in the end left it simply with 'major browsers'. Feel free to disagree.

Implications

If this is right, then it turns out that Flash and Silverlight are not part of the Open Web. I think this is perhaps what many people intuitively feel. I'm not sure that either qualify as user-remixable and they are not shipped with the majority of browsers either.

I wondered about defining the term based on browser usage: For example: "The open web is the technologies available to 80% of the web using public". But this is bad because it's against innovation. The old and dying, but still highly used browsers get to hold the open web back, and it opens up the chance that one browser can get to define what the Open Web is. The whole idea behind 'Open' is lack of lock-in. Maybe the Web is defined in this way, but not the Open Web.

I think this definition builds in many of the concepts of Decentralization, Transparency, Openness that Brad originally argued for, and stuff that is not explicit is perhaps included by implication.

There are some interesting implications for Gears in this proposal. While the purpose behind Gears is to support the Open Web, it is itself not part of it for the same reason that Flash and Silverlight are not.

Lessons from Hosting a Website

Tue, 22 Jul 2008 16:46:29 GMT

You might have noticed that the getahead.org domain has been replaced by directwebremoting.org. There’s a story behind it ...

3 years ago when DWR started to be successful, I bought 2 identical servers, built them identically with the latest Debian, and latest Drupal, bought some hosting space for one of the servers and kept the other at home as a backup with a nightly rsync, and thought I was doing a good job of managing a website.

The first thing to go wrong was Drupal dropping support for several of the modules that we were using: the theme engine, and the wiki module. So we were stuck on an old version of Drupal unless we spent lots of time recreating the themes and updating all the content. Lesson: 3rd party modules are OK but don't depend on them in a big way.

We realized we needed to upgrade, but it was a big job and when I began talking to the Dojo Foundation about them hosting DWR and talking to SitePen about me working for them, it seemed sensible to do the upgrade when we moved to Dojo Foundation hardware.

Then the backup died. Is it just me or does everyone assume that the live server will die first? We hoped that we could get everything onto the new hardware before the live server died.

The bad news is, but if you buy identical bits of hardware, then there is a good chance that they will have identical failings. That proved to be true in our case and we ended up with a huge rush to get everything moved to new servers, which included a fair bit of downtime. Sorry if it affected you.

I’m not sure if this is a reason to buy different hardware, where do you stop after all? Do you insist on different copper vendors for the power cable? The lesson is - if you discover a hardware fault in some part of a live site, the same thing is likely to happen to other identical hardware.

The good news is that the DWR website is now back on new hardware and a new URL. http://directwebremoting.org/dwr/. We’ve tried really hard to ensure we’ve got re-directs for all URLs, but please give us a shout if you notice that anything is 404ing.

Useful Feeds

Fri, 23 May 2008 11:59:17 GMT

How many blog posts start with the words "Sorry I've not been blogging much recently, but I resolve to post more often from now". Such a post may be followed by some actual substance, before the silence re-starts.

This is not one of those posts.

Getahead used to be the only place I blogged, but I've infected a few other feeds. I generally don't spend ages linking from one blog to another - I figure you can subscribe to the others if you want that content, however you can't do that if you don't know they exist.

I'm not closing this blog down, however I expect to blog less here. The good news, however, is that I hope that means that the subject-to-noise ratio will go up and not down. Stay tuned.

Both of these blogs are multi-author, 'professional' blogs. By professional, I mean peer-reviewed posts and no cat pictures - you can get those elsewhere.

CometDaily is written by the people that have spent the most time working on Comet. I've been busy this week so:...

On-board vs. Off-board Comet is about 2 architectural styles around how to deploy comet. DWR typifies one style. It's taken (in part) from the Comet BOF that Alex and I did at JavaOne.

Comet and Cross-Site Scripting is about how comet could supercharge a web worm so it becomes more virulent than a Warhol Worm. Samy took MySpace down with a web worm in 23 hours. I think it might be possible to reduce this time to about 6 seconds.

I work for SitePen along with a long list of similar techies. Our blog generally one post per day, about Ajax, Dojo, DWR and Comet.

Servlet Spec, Comet and Java is about how to work around Java's servlet spec to avoid needlessly chewing up threads. It looks at the options provided by Jetty, Grizzy, Tomcat and the new Servlet Spec.

And clearly, like everyone else, I tweet from time to time. In between tweeting, like everyone else, I mostly complain about how I can't tweet because Twitter is so unreliable.

Still no cat pictures, but I don't get peer reviews on my tweets.

Big Question for Sun

Mon, 19 May 2008 12:35:45 GMT

It looks from the outside as though every spare resource that Sun has is going into JavaFX. JavaFX may or may not win against Flash/Flex/Air/Silverlight/Android/Ajax, but while Sun is concentrating on FX, it doesn't appear to be giving the Java language the updates it badly needs.

Maybe Sun sees Java as 'done'. OK, but the Java language has one of the largest developer communities in the world, and they'd like some direction. Where do Sun recommend they go for their server-side development needs in 5 years time?

Maybe Sun think we should change to JRuby, Scala or Groovy. Maybe there are updates to Java that I don't know about. If none of the above are the case, the community will eventually disappear into mish-mash of languages that doesn't have the strength of numbers.

3:19pm Update: tweaked last paragraph to make the point clearer.

App Engine and Java

Wed, 09 Apr 2008 19:49:56 GMT

The world is now split into Python programmers, making funny 'Goo' noises over App Engine, and everyone else who are wondering when/if this will be available in their language or if they are going to have to change their spots.

Of all the languages to support, I guess Java must be one of the hardest because of the heavyweight runtime and the difficulty in separating code. But it also makes sense because supporting Java might give you quick access to Ruby/JavaScript/etc.

I have no knowledge of if Google are going to support Java in App Engine, however there are some tea-leaves that can be stretched and rearranged to form a vague picture.

Some time ago Google hired Greg Czajkowski the lead of Project Barcelona from Sun. Project Barcelona was where Isolates (JSR-121) came from and the Resource Consumption API (JSR 284), both of which would help you do this sort of thing. And both of which are now in Final Draft stage.

I have no idea if this does mean that Google are working on App Engine for Java, but if they do I'm going to claim bragging rights for having blogged about this 18 months ago.