DWR: State of the Union
So DWR is now part of the Dojo Foundation. I thought it would be good to quickly summarize where we are, and what I'm working on, and to give everyone a chance to comment.
DWR 2.0 has been out for 6 months or so. At the time, I swore that the next release would be a small one, called 2.1. However it appears that I’m not good at swearing because there is lots in the next release - I think we’re going to have to call it 3.0.
Just as a quick recap, here’s what changed with 2.0:
- Reverse Ajax which I define as Comet or Polling or Piggyback, whichever works best.
- Spring Namespace support, Guice support, Annotations etc.
- etc. Every release needs some etc. See the release notes for more.
Since 2.0, we've been working on the following adding support for JSON, Bayeux, images/binary file upload/download, a Hub with JMS/OAA support and more reverse ajax APIs. I also want to get some Gears integration going.
There are also a whole set of non-functional things to consider:
- Moving the website to directwebremoting.org
- Restart chasing CLAs, using a foundation CLA rather than a Getahead CLA
- Get some lawyer to create a CLA so Getahead can grant rights to the Foundation (or something similar)
- Get someone to pony up and let us move to SVN
- Unit tests
DWR Hub and integration with JMS and OpenAjax Hub: We have a hub, along with one way integration with JMS. The OpenAjax portion will be simple except for the getting the OpenAjax Hub to work smoothly with JMS part.
Reverse Ajax Proxy API Generator: The goal with this is a program that will take JavaScript as input, and output a Java API which, when called, generates JavaScript to send to a browser. Some of this work has been tricky, but then meta-meta-programming was always bound to be hard. This currently mostly works with TIBCO GI, but more work will be needed to allow it to extract type information from other APIs. You can see an example of how this is beginning to evolve in yesterday's article at The Server Side. I hope we will be able to create some Dojo integration for 3.0 too.
JSON support: One goal is a RESTian API so you can do something like this: http://example.com/dwr/json/ClassName/methodName/param1/param2 and DWR will reply with a JSON structure containing the result of calling className.methodName("param1", "param2"); It would be good to support JSONP along with this. We might also allow POSTing of JSON structures, although I’m less convinced about this because it quickly gets DWR specific, and then what’s the point of a standard. Status - DWR has always used a superset of JSON that I like to call JavaScript. We do this to cope with recursive data, XML objects, and such like. I’ve done most of the work so that DWR can use the JSON subset, but not created the ‘handler’ to interface between the web and a JSON data structure.
Bayeux Support: Greg Wilkins (Jetty) committed some changes to DWR, which need some tweaks to get working properly. Greg still intends to complete this.
File/Image Upload and Download: This allows a Java method to return an AWT BufferedImage and have that image turn up in the page, or to take or return an InputStream and have that populated from a file upload or offered as a file download. I’ve had some bug reports that it doesn’t work with some browsers, also we need to find a way to report progress to a web page simply. See this post on Ajaxian for more.
DOM Manipulation Library: Currently this is limited to window.alert, mostly because I’m not sure how far to take it. There are a set of things like history, location, close, confirm that could be useful from a server, and that are not typically abstracted by libraries.
Gears Integration: I’ve not started this, but it needs to take higher priority than it currently does. It would be very cool if DWR would transparently detect Gears, and then allow some form of guaranteed delivery including resending of messages if the network disappears for a while.
Website: We need to get the DWR website moved away from the Getahead server, and onto Foundation servers. There will be some URLs to alter as part of this, and I don’t want to lose Google juice by doing it badly. The documentation for DWR 2 was not up to the standards of 1.x, and while it has been getting better, we could still do more. One thing that has held this back has been lack of a DWR wiki. I hope we can fix this with the server move.
Source Repo: We are currently using CVS hosted by java.net. They support SVN, but want to charge us a few hundred dollars to upgrade. I expect to move away from collab.net/java.net CVS some time early next year.
Unit Tests: I've been trying for ages to find a way to automatically test with multiple browsers and servers. WebDriver looked good for a while, but it doesn't look like the project is going anywhere particularly quickly, so I'm back trying to get Selenium to act in a sane way.
Etc: There's always 'other stuff'. I've particularly not gone into things like Grizzly support. There's plenty of etc in this release too.
Browser Wars
Alex:
To get a better future, not only do we need a return to “the browser wars”, we need to applaud and use the hell out of “non-standard” features until such time as there’s a standard to cover equivalent functionality. Non-standard features are the future, and suggesting that they are somehow “bad” is to work against your own self-interest.
Ten years ago, in 1997, some people spent ages getting DHTML pages working across IE and Netscape, and when we were done we felt dirty and bruised. Some of us crawled back into our caves resolving that stabbing ones-self repeatedly with a sharp object was more preferable.
However, some people saw it as an opportunity.
In 2007, the people that saw it as an opportunity have created Dojo, YUI, JQuery etc. So this time around we're ready for them, and it doesn't have to hurt. This time around it's a matter of waiting for Alex, John etc to have taken all the pain and revved the frameworks.
Comparing the Evolution of Java and JavaScript
Java:
Java is the most used language in the known universe. It is also a very simple* language. Some people believe that there is some scope in enabling Java to accommodate more programming styles (e.g. functional programming via closures). Others believe that being lightweight is a virtue.
JavaScript:
JavaScript is the most deployed language in the known universe. It is also a very simple* language. Some people believe that there is some scope in enabling JavaScript to accommodate more programming styles (e.g. by adding classical inheritance not just prototypal inheritance, and an optional type system). Others believe that being lightweight is a virtue.
Features:
It's interesting that the current simple version of JavaScript already has the features (i.e. closures) that people want to keep out of Java otherwise it will become too complex, and that Java already has some of the features (i.e. classical inheritance) that people want to keep out of JavaScript, otherwise it will become to complex.
Crossroads:
The Java language is challenged by languages such as Ruby, Groovy and even Scala, all of which support closures. The majority of people that have spent serious time with these languages prefer them over Java for at least some set of problems.
The JavaScript language is challenged by Silverlight. Microsoft try to avoid saying things like "death to Ajax", but secretly (or not so secretly depending on who you talk to) they would love to control the platform once more, and Silverlight is the latest attempt at regaining control.
Features vs. Complexity:
Joel noticed that there is a big difference between good developers and bad developers. Google noticed it with it's picky hiring process. On many projects there are a few developers that do all the real work, while others just slow things down.
But much of the "keep complexity out of the language" debate is aimed at helping the people that write less code anyway.
Nail-guns and angle grinders are dangerous tools, but the building trade accepts the danger in the name of greater productivity. In software development where the difference between good and bad developers is that much greater, and where developers don't actually get physically maimed, the argument for power over simplicity is that much stronger.
In summary, extra power helps smarter developers work more quickly, but makes life harder for less smart developers. Since a small number of smarter developers generally do better work than a large number of no so smart developers, we should tend slightly toward giving developers more powerful tools.
Java:
In Java, BGGA closures enable higher-order programming. It's hard to say that the addition of closures in and of itself would cause a complexity implosion, after all, Java is virtually the only modern day programming language without them. It could be argued that the Java language can't be evolved to accommodate them, but I'm leaning towards there being a net gain by including them.
Interestingly, Google Android contains a clean room re-implementation of Java. If Sun (or the JCP) accepts closures, and if (as seems likely) Google votes against them, what will happen to Android? Will it follow how Google votes, or how Java evolves?
JavaScript:
With JavaScript, people see a neat, compact language and fear it turning into Java. The good news is that it won't fully turn into Java because JavaScript already has closures and no one thinks they should be taken out ;-) The danger of the "features over complexity" argument, is that it can be applied indiscriminately, creating a monster, and the fear is that JavaScript will become a monster.
I'm gradually coming round to the opinion that many of the changes proposed to JavaScript actually reduce complexity. There are nearly as many frameworks that add classical inheritance to JavaScript as there are Ajax frameworks. Having one solution that we can all agree on can't be a bad thing even if you prefer prototypal inheritance.
*: For some value of simple. The exact definitions of simple used in these 2 paragraphs are not necessarily the same.
Changes for DWR
This is very good news for DWR and for Ajax on Java.
The short version is that DWR is now part of the Dojo Foundation and that I now work for SitePen. This means that I'll be working nearly full-time on DWR rather than spending part of my time stuck in a big enterprise with Word as my IDE churning out technical architecture documents.
There are a whole bunch of questions that I just know I'm going to get asked:
Does this mean that DWR is going to become part of Dojo?
No. DWR will remain totally independent. There are some bits that I'd quite like to steal (JS compression for example) but you won't need to use Dojo if you want to use DWR or the other way around.
What's going to happen to Getahead and the DWR website?
For some time you've been able to visit www.directwebremoting.org and get redirected to the DWR website. We'll be moving the DWR website over to Dojo Foundation infrastructure and making use of the new domain at the same time. I'll be keeping my blog at Getahead for now at least. Consulting deals that Getahead would have done in the past will now be done by SitePen.
Who are SitePen?
SitePen employ a bunch of cool hackers: Alex Russell and Dylan Schiemann and many other Dojo people, Kevin Dangoor (Turbo Gears), and many more. They offer support packages for Dojo and now DWR, but also develop complete solutions.
What's happened to the TIBCO deal?
It's not gone away. I'll still be working to enhance DWR's Reverse Ajax proxy APIs, which from the next version of DWR particularly should aid DWR/GI integration.
Kevin Hakman from TIBCO is quoted on the official press release:
"Development teams, both small and large, have quickly discovered the benefits of using DWR in conjunction with leading Ajax libraries like Dojo, TIBCO General Interface, Scriptaculous, and others. DWR joining the Dojo Foundation is a great win for the DWR community," said Kevin Hakman, director, TIBCO Software, Inc. who has been a corporate sponsor of DWR's development for more than a year. "The close alignment of these projects, and the anticipated integration points between them, will serve to further simplify creating Ajax applications for Java developers."
How to make JavaOne better
Dear Sun,
You recently asked for my feedback as a previous attendee of JavaOne. I'd like to add the following to my comments about how to improve things:
Please, please, don't force the trademark lawyers change my presentation.
Each year the lawyers get to hack about with my presentation. Last year I had a slide that said DWR could:
"Use Java EE role based security to declare roles that can access methods"
However, this got changed to:
"Use Java™ Platform, Enterprise Edition (Java EE platform) defined role based security to declare roles that can access methods"
And when I claimed that DWR could marshal:
"JavaBeans and Objects"
This was changed to"
"JavaBeans™ architecture and Objects"
This is now technically incorrect - DWR can't marshal the entire JavaBeans Architecture - it might be cool if it could, but it can't.
The logic behind the trademark changes are that Sun are seen as the publisher of the presentations, so for them to publish the talks without proper trademark usage could lead to a case that Sun have lost their trademarks.
However, in reality, Sun have published in literally thousands of places on the web without the correct trademark phrasing. The (TM) symbol is missing from virtually every use of the word 'Java' on Sun's website, so why confuse presentations by insisting on strange phrasing there. Why not worry about java.net, where I can freely alter text without worrying trademark lawyers?
Please, please, make the presentation template ultra-minimalist.
How many of the presentations on SlideShare would be improved by the use of a standard template? Talking of which, this presentation is one of the most popular presentations ever on SlideShare ever. It would be destroyed by a template.
The presentation from Asa Raskin's brilliant talk "Don’t make me click" from the Ajax Experience was just a series of icons, where the point was made through the icons. Again, a presentation template would have destroyed the talk. The same goes for Dick Hardt's seminal "Identity 2.0" talk from OSCon 2005.
Many postings on Presentation Zen are about the problems of bullet points, but the presentation templates encourage people to use bullet points and to get sucked into the trap of reading from the slides.
I totally understand the need for some branding, but it doesn't need to be on every slide, and it shouldn't discourage people from being creative in how they present.
I like creating a good presentation, but whenever it comes to creating a presentation with a mandated template, I feel that some of the opportunity for creativity has been taken away, and the presentation suffers as a result.
Thanks for listening,
Joe.
What do you think? Is a conference helped by having a common theme across all presentations?
Update: Hani makes the good point in the comments that there is time in the 'Speaker Ready Room' to fix the problem. This is true, and I've spent several hours doing just that. However, if Sun just dropped the whole lawyer review thing, they could push back the deadline for slides, which might mean that talks were not 6 months out of date by the time they were presented.
Cringely and bad password advice
Cringely may know enough about social security fraud that the DHS want his advice, but I'm not sure he's got good advice about password security.
He starts well:
Identity thieves... can start a sweepstakes website that requires only free registration to win that cruise of a lifetime to Bora Bora. And in doing so the thieves can know that a majority of registrants will use a username and password combination that they also use at a lot of other sites, like bank and brokerage accounts. Not only don't they need to actually award the cruise, they don't even have to break into your bank account in order to benefit from the username/password combo. They just sell that information to another crook.
But the conclusion:
So CHANGE YOUR DAMNED PASSWORDS and put an end to this kind of scam. Perhaps remembering new character strings will help to stave off Alzheimer's.
This has to be terrible advice:
If the crook can get to your bank, and work out that you've used the same password details (he doesn't say how the crook is going to get your bank account number) then one thing is certain - the crook can get there faster than you want to change your passwords. Suppose the crook is going to sell the personal info that night in the pub to a mate whose going to plug the data into his account cracker later on that week. That means you should be changing all your passwords at least once per week. And that's only going to stop the slow crooks.
Things that help password security:
- Complex strings that are not guessable.
- Passwords that differ from site to site
I'm yet to see any situation where changing your passwords helps. If the bad guy once knows your password and can impersonate you, the chances are that he's changed your password and locked you out, or installed a backdoor so changing your password doesn't keep him out anyway.
So how do you use a different complex passwords on each site and still remember them all?
This is a good trick. It uses 3 components:
- Pick a random string of 4 characters containing upper/lower case letters and numbers. e.g.
tS8j - Decide on a way to mangle the domain name of the website to get 3 letters that are not obviously related to the domain. Suppose you want 3 letters from google.com. You could pick the 3 from the end in reverse order:
elg, you could type the first three letters one key up on your keyboard:t99, you could Caesar shift:hpp, pick the middle 3:oog, etc, etc. - A single digit/letter that you can increment (or decrement) when someone insists that you change your password.
Then put those characters together in some order, so you might end up with tS8jelg0 or oogAtS8j. Then use the same system, with the same set of 4 random characters, just changing the 3 characters per domain and the one character whenever someone forces you to change.
This may sound overly complex and paranoid, but it is lots easier than changing your passwords on a regular basis, and far more secure.
Using regularly changing passwords just forces you to use simpler passwords to avoid forgetting, and simpler passwords are far more of a risk than re-using passwords, or using guessable ones.
The rise of Comet
Comet Daily is new - dedicated to all things Comet. The idea, if we can get enough content, is to have regular - even daily, postings on the growth of Comet.
There are a whole bunch of people writing, and claiming that they are going to be writing.
It's easy to disparage Comet as just Push, and to remember PointCast. But 1995 was the wrong side of the Ajax boom and the wrong side of the whole social explosion. The tipping point is where those 2 trends crossover - which is the point of my first article:
Web Application Security
A few people asked for slides and links from the security talk from The Ajax Experience last week:
General Links:
- OWASP: Open Web App Security Project
- Security Resources from the OpenAjax Alliance Wiki
- Mozilla on Same-Origin Policy
XSS:
- Introductions from: Wikipedia and Apache
- Cheat Sheet: Long list of XSS vectors from RSnake
- Explanation of DOM Based XSS
- Explanation of Samy is my Hero worm
- Fairly old FAQ at CGI Security
- List of XSS holes in popular web applications
CSRF:
- Introduction from: Wikipedia and here
- Article by Chris Shiflett and CSRF Redirector test tool
- CSRF FAQ at CGI Security
- Array constructor overriding and setter overriding
- A solution: SameRefererOnly
- Protecting a JSON or JavaScript Service
Blogs:
Comet talk from FoWA
Here are the slides from the talk I did at Future of Web Apps in London last week.
Quite a few of the other talks have been uploaded to the same place:
Dion Almaer: Future of Web Apps: Google Gears
John Resig: The Future of Firefox and JavaScript
Matt Mullenweg: Architecture Behind WordPress.com
Suw Charman: Preparing for Enterprise Adoption
Leisa Reichelt: Ambient Intimacy
Rashmi Sinha: Making Your App Social
Matt Biddulph: Coding on the Shoulders of Giants
Simon Wardley: Short on cycles, long on storage
Heidi Pollock: Taking Your Application Mobile
