When I heard news that Google was to release a spreadsheet companion to their freshly bought Writely web-based word processing app, I got excited about all the things they could do to make it more than just a copy of Numsum. Let’s face it, Google’s the Gorilla in the room here and they’re gonna squash Numsum, but wouldn’t it be cool if…

Well, Dmitry Nekrasovski get’s credit for planting the notion of URL-addressable rows, columns, and cells in my mind with this commentary from months ago:

I just came across this ITWorld article that suggests a simple yet intriguing idea for making online spreadsheet applications like Numsum more than Excel wannabes: make cells and cell ranges addressable with URL’s, and use a standard XML variant to encode them. To the author’s credit, he does not use a buzzword for this idea, but, for ease of meme-peddling, I will refer to it as Spreadsheet 2.0. You heard it here first.

The implications of Spreadsheet 2.0 at the user experience level for a public site could be pretty neat: feeding into a live stream of, say, stock market data could be as easy as copying and pasting a spreadsheet cell. But it could be most valuable in an enterprise environment. Anyone who has worked in a large organization will testify to the pervasiveness of the “spreadsheet mentality” and the difficulty of managing and reusing data once it is buried in a spreadsheet. Could this be a legitimate way for Web 2.0 apps to find their way to large-scale enterprise deployment?

Now, go one step beyond read-only URL-addressability and think about writing to cells with an HTTP post URL. Imagine the way cool apps we could build based on that.

Thanks go to Jessamyn for inviting me.

google, google spreadsheets, office application, office software, spreadsheet, spreadsheet 2.0, url-addressable, web 2.0, web application, web20, webapp

New AJAX-happy CMS: MooFlex, more info at Ajaxian (and in their podcast).

cms, opensource cms, web application, mooflex, ajaxian, content management system

I have plans to apply AJAX to our library catalog but I’m running into a problem where I can’t do XMLHttpRequest events to servers other than the one I loaded the main webpage from. Mozilla calls it the “same origin policy,” everyone else calls it a cross-domain script exclusion, or something like that.

Some Mozilla folks are working on a standard to address the problem, but it could be quite a while before browser support is common enough to build for it.

So Plan A was to use simple AJAX with XMLHTTPRequest. Plan B comes from this crazy suggestion at Apple’s developer site: Remote Scripting with IFRAME. It looks like different functions are subject to different restrictions, so the theory is that a JavaSctript loaded in a page in a hidden IFRAME can call functions from the parent page and do pretty much everything we’ve come to expect of XMLHTTPRequest. Here’s an example they offer.

Crazy as it is it works, and it gets around some cross-domain script exclusions for some browsers, but it still gets trapped by Mozilla.

tags: ajax, apple, browser security, browsers, cross domain, cross domain script exclusion, frustration, iframe, javascript, mozilla, remote scripting, web application, web applications, xdomain, xmlhttprequest