How long did it take Web 2.0 to turn into Bubble 2.0? 6 months at most?

It's now 9 months since the Ajax term was originally defined, and I'm yet to find the pin to burst Ajax's bubble.

Several cool things have happened to DWR recently. The most bizarre has nothing to do with the web at all.

Being from the UK, I'd never heard of Design Within Reach until I started work on Direct Web Remoting. I doubt they've heard of Direct Web Remoting, but recently they did an announcement made me do a double take: DWRjax looks like it should be a DWR Ajax mashup, but really it's kids furniture.

Other News

According to the recent survey by the Burton Group, DWR is doing very well in terms of the numbers of people using it. They found that 68% of the people using Java/Ajax libraries are using DWR.

Matt Raible has included DWR into both AppFuse and Equinox. I also noticed a blog about getting them to work together.

Also Pete Moore from Cenqua got DWR included in some FishEye reports. You can get the results at fisheye.cenqua.com.

DWR 1.1 beta 1 has been released and is available for download.

The feature list for 1.1 looks like this:

• New ObjectConverter (called 'object') that reads fields rather than bean getters and setters. Includes a 'force' parameter to read from private fields
• New parameter to BeanConverter that allows you to specify an implementation. This allows you to convert according to an interface but create some implementation of that interface
• Basic support for synchronous calling, either use DWREngine.setAsynchronous(false) or meta-data - { asynchronous:false, callback:function(data) {...} }
• Most remoting options can now be set on a global, batch or call level. The remoting options are: timeout, errorHandler, warningHandler, [pre|post]Hook, method (XHR/iframe), verb (GET/POST), ordered, synchronous
• Exceptions are now marshalled across Ajax (without stack trace information) which can help to know what has gone wrong.
• Added EnumConverter (called enum). Enable it in an allow section like BeanConverter
• ScriptedCreator and SpringCreator now have a setClass method that allows you to specify the class that they create without having them go through the motions to find out what it is and then throwing it away
• Added WebContext. WebContext will take over from ExecutionContext at some stage to enable features in a later release
• Several bug fixes

Technorati tags: DWR, AJAX

I've just been using Copilot, the Fog Creek version of VNC that makes it easy to fix someone else's computer.

Normally I'd get away with the Help and Support wizard in XP, but that won't work if (like the client I was helping) you are behind 3 firewalls.

Copilot works by allowing both parties to connect to Fog Creek servers, which is a simple way around many firewall issues.

This is what I found:

• They've got ease-of-use nailed. They sent my client a link to a single file executable that included my connection information, so all the client had to do was run the .exe. No installation, no fuss. Microsoft could learn a lesson here.
• It's easy to use from an admin (i.e. the helper) point of view too, although this is less of a big plus point.
• The refresh rate isn't as good as remote desktop in XP, for the most part this isn't a huge issue, although it can be annoying. WinXP's help and support is just about usable over a modem, but I suspect Copilot would not be to all but the most patient.
• You might have privacy concerns about sending your data via a 3rd party, although I guess that very often, the helper doesn't care (it's not their screen going over the net) and the helpee is only to glad to have their problem fixed.

Worth a look if you need to help someone out when they are behind a firewall that you can't get around easily. $10 for 24 hours saved me a lot of time in a car yesterday.

Matt recenty blogged about the best way to integrate Ajax into a Java webapp and promoted DWR: "The best thing that I've seen is to use DWR, Prototype and Scriptaculous". As the main developer of DWR clearly I'm going to agree that it's a great solution.

Every now and again someone asks about adding a JSP layer on top on DWR, so here's my take.

First I'm not against the idea. If you are using JSP as your view layer and neither know nor want to know Javascript, then an Ajax tag solution could help you a lot.

The biggest reason that DWR has not addressed the issue is that I believe in doing one thing and doing it well. DWR does the RPC thing and it lets you put your data on a page, but we try really hard not to get sidetracked.

I've been tempted to add JSP layer to DWR and I've been tempted to add a widget library to DWR, but resisted both.

So if JavaWebParts, AjaxAnywhere or AjaxTags or anyone else wants to build a tag library using DWR's abilities to marshall data over XHR then give me a shout, I'll help where I can.

However that said, don't give up on Javascript. It will give you the ability to stretch your web page in ways that a tag library never will, and libraries like Dojo, Scriptaculous and DWRUtil can really help give your pages some serious extra juice very easily.

Responses[2]

Posted by Joe Walker on 17 October 2005 19:08:20 BST #

Update: I've created a new permanent page for my Venkman patch:

Old blog content:

Firefox 1.5 beta 2 is ready for download. See also the release notes and the list of new features. This is the last planned beta before the release candidates.

I've updated my hack on the Javascript debugger (Venkman) so it will load into the new browser. You can get the installer package.

Please give me a bit of feedback if you find this useful.

Responses[9]

Posted by Joe Walker on 07 October 2005 11:14:04 BST #

Ajax, Internet Explorer, Netscape, GMail and Outlook on the Web - the story of how to learn from your own past.

All the way through their anti-trust trial Microsoft were claiming the right to innovate, and everyone else was pointing out how little Microsoft actually innovated new ideas, and usually just purchased the new ideas.

The truth was probably somewhere in between the two. One case however where they really were guilty of total lack of innovation was with Internet Explorer, where they let it sit for years without touching it.

Irony 1

In the anti-trust trial, Microsoft were accused of killing Netscape with their desktop monopoly. Microsoft accused Netscape of killing themselves by failing to update their browser for ages.

Following the trial Microsoft copied Netscape by failing to update their web browser and so losing market share; Thus proving both that the were right (Netscape did contribute to their own decline) and that they are silly enough not to learn from their own recent past.

Why did Microsoft stop updating IE?

During the 90s they became worried that if you can do everything you need through a web browser, then you wouldn't need Windows. Linux+Firefox or MacOS+Safari would do just fine. So they wanted web browsers to be the poor relation of Windows.

However one area where Microsoft really did innovate during this time was the invention of the ActiveX control behind Ajax; this ActiveX control was created for Outlook-On-The-Web. They are just now starting to be rightly proud of an invention that really does alter the way the web works.

They didn't mean to fundamentally alter the web - all they meant to do was to write a cool web based e-mail program. But they did both.

Irony 2

The really big irony is that while they were arguing about how much they were innovating, they were having a policy of not innovating on the browser front at all. However while they were trying not to innovate they accidentally created an innovation that could end up killing the very thing that gave them the monopoly in the first place.

The fears of the 90s are starting to come true; partly thanks to Ajax, the Web is becoming a more successful platform than Windows is.

The irony meter is now pegged.

Irony 3

Ajax was made possible by an ActiveX control that enabled Microsoft to write a very cool web-based email program. Maybe they realized the potential of what they had created and decided to keep it quiet, or maybe they just forgot how cool it was, but the ActiveX control went very un-sung for a number of years until it was made famous by another web based email program - GMail.

I'm sure we'd call the script contrived if we read it in a book.

Robert Schoble

Nothing to do with Ajax, Netscape or Webmail, but everything to do with Microsoft and foot shooting; I noticed that Robert Schoble is moving his blog. It was hosted at weblogs.com, but it looks like he is going to Wordpress. Isn't that going to be a foot shooting? I wonder what percentage of his current subscribers will re-subscribe? Can the problem of where his feed is be solved using 302 redirects? Maybe he should be moving to an RSS redirection service like feedburner instead. It will be interesting to see how this pans out.

Microsoft announced that they were going to support the native XMLHttpRequest object in IE7. This changes how you should do Ajax calls ...

With IE5.0 - 6.0 the only option for Ajax calls is one of the ActiveX objects (Msxml2.XMLHTTP, Microsoft.XMLHTTP, etc), however with IE7 the will support the window.XMLHttpRequest object.

Why are they doing this? Is the ActiveX control not good enough? Are there bugs that can not be fixed in the ActiveX control?

I think the reality is that Microsoft would like to deprecate ActiveX completely. It can't be done today without breaking things, but it makes good sense in the future. Microsoft are already changing things in that direction; IE6 in Windows Server 2003 runs with ActiveX disabled and in Vista installing new Active objects has been made harder.

Depending on how the ActiveX Ajax object is retired, and how bugs are fixed in the various IE7 implementations we need to be using the native XMLHttpRequest object in preference to the ActiveX objects starting now.

So, wrong code:

var xhr;
if (window.ActiveXObject) {
  xhr = new ActiveXObject("Msxml2.XMLHTTP");
}
else if (window.XMLHttpRequest) {
  xhr = new XMLHttpRequest();
}

This is wrong because it will be using the ActiveX control in IE7 in preference to the native XMLHttpRequest object.

Instead we should be doing this:

var xhr;
if (window.XMLHttpRequest) {
  xhr = new XMLHttpRequest();
}
else if (window.ActiveXObject) {
  xhr = new ActiveXObject("Msxml2.XMLHTTP");
}

I just checked with the DWR code which gets this right (purely by fluke - I can't claim fore-thought on this one) but a number of other big implementations get it the wrong way around.

Responses[4]

Posted by Joe Walker on 03 October 2005 10:15:48 BST #