brentashley

Not only are the tools and techniques surrounding Ajax development maturing, the very scope of the Ajax meme continues to expand even now, two years since Jesse spake those immortal words back in 2005.

The latest class of techniques to come under the umbrella of Ajax is offline browser applications. At the Ajax Experience conference in SFO last week, there were a few presentations about the Dojo Offline Toolkit, which provides offline application and synchronization abstractions on top of the Google Gears local storage engine. I spent quite a bit of time with Brad Neuberg and his work on DOT is impressive.

Another topic that got much more coverage this time around was Performance Analysis and the tools you can use. Ryan Breen had a great talk that described some very useful tools and Steve Souders presented his new tool YSlow.

I had a chance to hang around with lots of other great folk while I was there – Douglas, Brendan, Sean, Dylan, the charming but unlinkable Stephanie Trimble, John, Pete and Dori to name a few. And of course, Ben and Dion, congenial hosts as always.

Although you will indeed see me at the Ajax Experience show in SFO at the end of the month, I’m afraid you won’t find me in Santa Clara in September.

Today I received yet another in a series of communications asking me to be a sponsor for the Ajax World conference hosted by Sys-Con Media.

I first had contact with Sys-Con when Jeremy Geelan asked me to participate in an expert survey in 2005 [addendum: Jeremy is no longer with Sys-Con, having left to found Social Computing Magazine][addendum2: Jeremy is back with Sys-Con – whether he actually left or not is unknown, but it’s clear he’s not been entirely frank with me]. I freely gave a bit of my time to come up with a series of responses which were quoted and which apparently were helpful in making it a successful article, ostensibly generating interest or revenue for them.

Based on the success of that interaction, Jeremy invited me to speak at Ajax World in Santa Clara, but it soon became clear I was expected to pay my own travel and accomodation and displace 3+travel=4 days of client business, altogether a significant cost to me – greater than $5000. I said that as an independent with no product to pitch, I would require travel, accomodation and compensation. I was told that expenses were my responsibility and all I could expect in return for speaking would be to get into the conference – a $1595 “value” to me.

Some time after declining this “generous” offer, I started receiving emails and even couriered packages filled with glossies and CD media from Carmen Gonzales, Sr. VP of Sales & Marketing, entreating me to pay big bucks to sponsor the show and get myself a speaking slot.

Jeremy later sent me an email inviting me to submit my presentation for the NYC show last fall. I did so, and reminded him of my requirements, wondering aloud whether his position had changed since he was asking me again. I never received a response.

After receiving further unsolicited emails [from Carmen] about sponsorship, I wrote to Carmen, copying Jeremy, to make it clear that not only had I no such interest, but that their continued efforts were beginning to wear on me.

Since that time I have received numerous messages and even packages via courier, entreating me to spend up to multiple tens of thousands of dollars to become a sponsor. It’s apparent that your business model consists of charging people to attend conferences to hear vendor representatives who have bought keynote and speaking slots and other speakers who have paid their own way and given their time for free, all sponsored by other companies who pay you handsomely for the privilege. It’s abundantly clear that any disinclination to budget for speakers has nothing to do with a lack of available funds.

Obviously there are many speakers whose situations differ from mine, and I salute you for your ability to maintain a cash cow with such a lopsided balance sheet, however, I’m not the least bit inclined to spend any of my own time and effort to further enrich your gain with no recompense to me, and your continued misdirected effort is doing nothing but alienating me from any desire to be supportive of your organization in any way.

For what it’s worth, I presented and participated on panels at both of the Ajax Experience shows last year with no such issues and was made to feel that my time and contribution were very much appreciated.

I was nearly knocked over when in response to my email direct to Carmen a customer service rep contacted me and I was offered a Gold Pass Badge to the NYC show.

Brent,

Our apologies for the oversight and mixup. We would love to invite you to AJAXWorld as our guest with a complimentary Gold Pass badge.

SYS-CON Events Customer Services Team

P.S. Jeremy and/or Carmen will reply to your email. Our apologies again!

In order to use this “complimentary” pass of course, I would have to fly from Toronto to NYC, pay for a hotel, taxi, etc, and of course jerk around my clients on short notice to realign my schedule.

I never received an email from either Carmen or Jeremy as promised by the Customer Service rep. I figured whatever, that’s the end of that.

So, today I start receiving the sponsorship emails [from Carmen] again.

Platinum Sponsorship: $30,000:
10×20 Exhibit Space & 50 minute vendor presentation

Gold Sponsorship: $20,000:
10×10 Exhibit Space & 30 minute vendor presentation

Silver Sponsorship: $15,000 8×10 Exhibit Space & power panel spot

Exhibitor Packages: Plus package $10,000 / standard $5,500

The entrance fee for the conference ranges from $1500 to $1900 depending on when you sign up.

It’s too bad they can’t afford to compensate their speakers or even pay their expenses.

It’s also a shame that their disinterest in stopping the mailings and their lack of response (even when promised) would lead me to moan publicly about it.

IBM Developerworks has just published my new article “Shaping the Future of Ajax Mashups”, wherein I explain that browsers are still not well equipped to enable mashups that integrate input from multiple sources without falling prey to serious security and/or scaling issues. I then discuss some of the potential solutions to the problem and call for the development community to get involved.

I’m also interviewed by IBM’s Scott Laningham in a short podcast promoting the article.

One good way to get involved is to mix with the top people in the Ajax world – the browser manufacturers, the folks who create the libraries and APIs we use to build our Ajax apps, the big players in the industry. Ben and Dion at Ajaxian have just made a call for speakers for their Ajax Experience 2007 show slated for July 25-27 in San Francisco. Having established some great contacts and communication at the two previous Ajaxian shows, I can tell you without doubt that this is the one Ajax show of the year not to miss. It’s an opportunity to spend a couple of days rubbing shoulders with the people in the industry who can actually influence the future of the tools we use to build and use the interactive net.

Douglas Crockford points out at the top of his blog that a patent was applied for in 2001 and awarded late last year covering using the <script> tag as a remote scripting transport.

Numerous people have “discovered” and exploited the value in using the script tag to get code and data on the fly since that time. It’s an obvious logical use of the functionality for which it was designed.

Of course, once a patent is granted, arguments about obviousness or originality can fall on deaf ears – the patent owner has the upper hand and it could cost you a lot to prove your case in court.

Beyond the obviousness, inspection of both the client and server side code for the patent reveals that most of it is copied directly from my JSRS library, published a year earlier, not only without attribution, but claiming it as their own “NetGratus Remote Scripting”. Of course, my license is very liberal, allowing reuse for pretty well anything, however it does say:

The only thing you can’t do is to restrict anyone else from using it however they see fit. You may not copyright it yourself or change the rules I have set on how it can be used.

So, if you’ve been asked to license this patented technology, I’d be happy to have a look at the particular code being offered for licensing and see whether it violates my copyright by restricting you from using it without a license.

Also, as Danne Lundqvist, veteran script tag advocate points out to the latest person who has independently had the script tag revelation, there are many reasons that the script tag is an inferior transport layer, not the least of which are the security implications as I pointed out just this week

The upshot is this: the script tag hack’s days are numbered. If you can change to XMLHttpRequest while waiting for JSONRequest, by all means do.

It’s rather ironic that the appearance of this patent will have had exactly the opposite effect that a patent should: Rather than the patent informing the world about a hitherto unknown invention, explaining its workings and contributing to the furtherance of knowledge, the patent in this case informs the masses of people who came up with the same obvious idea that they had better stop using this technique in order to reduce their liability regarding the injunctive power of the patent holder.

As I said in my last post, the current browsers were not designed with mashups in mind. The current methods in use to make mashups work result in either overly restrictive or overly permissive security issues.

Take XMLHttpRequest – calls are limited to the server where the current page originated. Can’t mash up without proxying through the server. Doesn’t scale well.

Take iframes – you can embed a page from another site, but due to Javascript same-domain restrictions, you cannot communicate with that page without some quite obtuse hackery on which you’d like to avoid relying.

Take the script tag – you can execute code from another site, however you have no opportunity whatsoever to inspect it for security before it gets executed, meaning there must be a lot of trust in the other end of the transaction and no hope of avoiding man-in-the-middle attacks. Using script tag methods, cross-site cookie access can cause privacy issues. Insecure, undesirable.

What we need is browser features that were designed with mashups in mind. We need them to be added to the browsers without having to wait until IE8 and Firefox 3 (…Safari 3, Opera 10, etc).

Douglas Crockford has a set of proposals that begin to give us an answer to this dilemma. He proposes:

• JSON – a lightweight data-interchange format
• JSONRequest – a Javascript object designed to exchange JSON-formatted data flexibly, efficiently and securely
• the <module> tag – an addition to HTML to create secure zones from multiple sites on a single page with controlled communication between them

JSON support is already on the way to being built into Javascript.

The main browser vendors are aware of JSONRequest and have begun talking about it together.

Douglas only recently proposed the module tag, and we as developers need to help the browser vendors to understand that we want to build secure mashups, so we want them to discuss amongs themselves and with ECMA and W3C how this proposal or any other will help us to do that.

Do your part to get involved with organizations like the OpenAjax Alliance to promote advances like the ones Douglas proposes.

I’m just starting to settle back in after getting back from last week’s Ajax Experience show in Boston. It was a great conference, with superb speakers, fantastic swag, and lots of really interested and interesting attendees. I was extremely pleased that my friends Pete Forde and Joey deVilla came along not only as attendees but to participate wholeheartedly at every turn. Toronto’s vibrant tech community was well represented by our collective presence.

When I attend these shows, one of my main objectives is to seek out people in influential positions who can work together to effect advances in the state of the art and to put them in front of each other in the hopes that some strides can be taken in a fruitful direction. I was really pleased to have had some success in doing that this past week. It’s not that these things wouldn’t happen without my being a meddling matchmaker, but I like to think that as an independent without ulterior motives I can help to accelerate the relationship building process.

One of the biggest challenges in the Ajax world is that the whole “data channel back to the server” piece doesn’t support mashups well. The solutions that support cross-domain access do so in limited or insecure ways, and the solutions that can be made secure or that afford superior control lack cross-domain access. The parts of the browser that we have used to perform these tasks were designed either for entirely different purposes or for subsets of what we now want to do.

Douglas Crockford is well known in Javascript circles. He has an uncanny ability to distill complex concepts and, using a remarkable economy of expression, present them in such a way as to be simple to understand.

In his first talk at the show, Douglas offered a series of proposals that together would enable developers to build mashed-up applications that are secure and robust. The key would be to get the browser manufacturers to implement support for JSON, create a new JSONRequest object, and introduce a new <module> tag (see Doug’s module proposal: it would provide compartmentalization of secure zones from multiple sites on a single page with controlled communication between them).

Even if Douglas’s proposals don’t end up being the solution to these problems that is implemented , I believe that he has provided the most comprehensive place to begin discussions towards fixing up the browser to be a place that was purposefully designed for mashups.

My small part in helping to kick this into gear was to get some of the players involved to socialize and begin to discuss common goals in these mashup issues.

I found myself talking on Tuesday afternoon to Sunava Dutta, the program manager on the IE7 team responsible for the native XMLHttpRequest object. I invited him to have dinner at our table and also got Brendan Eich (Mozilla Foundation) and Douglas Crockford to join us. Nothing of import came directly from any dinner discussion, but hopefully the seeds are sown for some great interaction.

As Douglas observed on the expert panel later that evening, the web development industry has been turned on its head in comparison to the early years. Whereas originally the browser makers drove the browser feature set and imposed it on the public, the web development community is now ahead of the browser providers in demanding features to support innovation. Our collective voices can influence them to improve the browsers to suit our needs.

I’m really looking forward to the next Ajax Experience (which should be in San Francisco in April I understand) to see how far along these initiatives have come. Ben Galbraith and Dion Almaer from Ajaxian and Jay Zimmerman of NoFluffJustStuff all deserve accolades for making this show perhaps the most important venue of the current web lifecycle by attracting both the elements and the catalysts necessary to build the brightest future for web applications.

I’m off to The Ajax Experience Boston Edition 2006 tomorrow. It starts Monday morning at the Westin Boston Waterfront.

This show is the event of the season and I’m looking forward to seeing everyone. It’s not just the sessions, it’s also the opportunity to meet top people in the biz – fellow Torontonians Joey deVilla and Pete Forde will be but two of the world class developer folks in attendance.

My presentation will be right near the end of the show on Wednesday at 11:00am in Grand Ballroom C. After lunch we’ll be hearing Brendan Eich‘s keynote speech about Firefox 2 (likely covering some of Javascript 1.7’s new features) just before the wrap-up ceremony.

I’ll be participating throughout the whole show on panels and in discussions, so by all means track me down and say hello.

I’ve been following advances in the Ajax world so I can keep my Ajax Transport Layer Alternatives presentation up to date for The Ajax Experience in Boston next month.

Harry Fuecks wrote recently about new approaches to Javascript asynchronous calls. It’s really neat stuff and I’m stretching my brain to try to understand it fully. I wonder though to what extent it will actually solve problems that really exist for most people any better than what already exists.

I’ve been making Ajax apps that work well enough for years while many people have been waiting for all the stars to align before they even try it. I’ve had all sorts of flack from pedants for using iframes and img/cookie because they’re hacks, but JSRS and RSLite have worked consistently and predictably across a large number of browsers for 5 years and more without modification. I only changed my Blogchat app to use XMLHttpRequest recently (for no really good reason – it’s been unchanged since 2002) and the first thing that happened was a huge debugging session to figure out a really wonky deep IE7 issue.

The thing about simplicity in the programming world is that it begets stability. The unknowns and dependencies introduced by layers of abstraction and frameworks and preprocessing can in some cases introduce far more potential complexity and maintenance issues than the problem at hand is worth. While there is definitely a class of complex UI problems that are now trivially resolved using the latest and greatest of libraries and frameworks, don’t forget that many simple problems deserve simple solutions.