1. You're only as productive as your network connection

If there's one downside which immediately strikes people upon mention of RIAs, it surely must be this one: no connection, means no application, means no data!

Right now and for the foreseeable future universal broadband internet access cannot be taken as a given, in the same way an uninterrupted electricity supply usually can. Ignoring the patchy coverage of wireless hotspots, even a wired broadband service in a major population centre can be subject too all-too-frequent brown or blackouts. There is one easy way to circumvent a problem like this, caching local copies of all data and code means we can fall back on said copies when necessary. But this solution is not without its own issues.

The problem is that until universal internet access is a constant, we need to rely on caching to deal with black spots, and so long as we rely on caching there is a chance other users may modify our work while we're out of the loop.

Yes, a technology like Subversion would provide the obvious solution here — except I've yet to encounter a revision control system that 'just worked!', without at least some advanced planning and the occasional spot of tweaking and administration along the way. If nothing else, the user has to be called upon to sort out incompatible edits in need of merging. What's a minor nuisance for us clued-up code monkeys becomes a source of major panic for your average computer illiterate user.

Some of these problems can be subdued by tailoring revision control to each specific application. A system which is designed specifically to understand a given type/format of data can be more liberal in the assumptions it makes and rely less on the user to organise and fix issues. But... revision control can be tricky software to write, and if done badly can become the source of errors and corruption — can we really trust each individual RIA developer to solve these problems themselves?

2. On the internet everyone could know you're a dog

Peter Steiner's infamous New Yorker cartoon voiced one of the selling points the Net evangelicals pushed when the web first took off, namely that the internet provided a egalitarian space where people were judged on the value of their ideas and contributions, rather than their sex, skin colour, age, etc. A true meritocracy, free from prejudice.

I suppose this was initially true, but the old prejudices soon returned. If you've ever tuned into any of the 'vblog' debates on YouTube you'll be all too aware that anonymity on-line is no longer the all-embracing thing it used to be. AngryAtheist and KentHovindFan no longer battle it out in monospaced text alone, how we can see them, hear them, and accordingly pass instant judgment on their character.

In some regards we seem to have an almost suicidal instinct to share with the world the details of our lives. Just ask any fresh faced college graduate who's been caught out by a prospective employer's well crafted MySpace search. Or the couple who got the contents of their house stolen after announcing their vacation to the world on FaceBook (admittedly this latter example smacks a little too much of 'urban legend' for me.)

RIA's push this level of exposure to the limit, and if the example of MySpace is anything to go by we cannot rely on the end user to understand the security implications of where they decide put their data. A responsible solution must protect the innocent — even when the innocent behave in such mind-numbingly clueless ways as to seriously cast doubt on Darwin's theory of natural selection.

Data stored remotely on a network server has two vulnerabilities. In part or whole it needs shuffling to and fro across a network, opening up the usual prospect of sniffing and substitution. It also requires absolute trust in the party you choose to store your data. While many of us wouldn't be devastated if a bored 'sys admin' read the great literary masterpiece we've been slaving away at (indeed, I know some luckless writers who would be thrilled at the prospect!), if our name just so happens to be J.K. Rowling we might have a different opinion.

With traditional desktop apps we at least have the option of never allowing sensitive data to leave our homes or offices, even if some choose not to exercise it. With RIAs that choice is largely removed. So cryptography becomes a necessity. But security is all too easy to get wrong — indeed in my experience it is far too often added as an afterthought, leading to cracks which leave open potential exploits.

Users of traditional desktop applications can rely on the operating system to give their data a minimum degree of security thanks to access permissions. They provide a basic level of inherent security without the developer ever having to think about it. RIAs may need some kind of comparable 'no brainer' security layer for transmitting and storing data, available universally. The alternative would demand each developer implement security for themselves from the ground up — surely a recipe for disaster?

3. File systems are not databases

When I started my professional career mainframes were still very much a going concern, at least in large financial institutions and government finance departments (the latter providing my first real work experience.) Most were not interactive: one queued up a run using a JCL (Job Control Language) from your terminal, then sometime later it might be plucked from the queue and given CPU. The output was delivered as hard copy, flick-n-ripped from a live 132 column line-printer as it machine-gunning its way through a rain forest sized box of continuous stationary.

The primary currency in such a world was the record. Software was merely a pipeline, shoveling records in at one end and spewing out a resulting record at the other, either to storage or printer. Ultimately this was not an environment which allowed a user to directly interact with their data, so whether the records originated in a file or a database was irrelevant — only the format of the data mattered.

But on the 'Micro Computer' things were different...

The currency of the Micro (aka, PC) was the file, not the record. We could duplicate them, move them around on floppies, back them up, we uploaded them so others could download them, and (with the birth of the internet) we traded them. Extensions like EXE, MP3 and JPG became more famous than the actual names of the formats they represented.

Web applications don't deal in files. There's no expectation you'll ever want to copy your GMail inbox to a flash drive, or drop a Flickr photo into an instant messaging conversation. Web application data lives outside the metaphors and conveniences of the desktop. Dragging a Writely document to the trashcan does not delete it, nor does double clicking it cause an appropriate editor to be loaded (assuming either of those two actions were at all possible.)

For Rich Internet Applications to be successful they need to marry the fidelity of experience from a traditional desktop application with the omnipresence of a web site. This necessitates the need to span the divide between web and desktop — which makes the problem of files such a thorny one. How can data held remotely, probably in a database, still appear to interact with familiar desktop conventions like 'the trashcan'?

Does it even need to? Could users learn to cope with a schizophrenic world where local data is referred to by file, and remote data is referred to by views into a database? Perhaps the answer is to ditch the notion of files on the desktop altogether? Imagine a computer were folders did not represent one level from a hierarchical file system, but filtered views from a pool of data items which lived on (or were immediately available to) your PC?

Conclusions

The above three comments represent aspects of internet applications I feel need addressing before RIAs can take there place alongside traditional desktop apps. I believe in all three cases the problems are largely solvable — specifically I believe all three could be solved via some kind of standardised, universal RIA 'operating system' or framework, allowing the developer to focus their efforts onto their application, rather than re-inventing the wheel with each project.

Not only does a generic 'operating system' like platform make it easier for data to be shared between applications (photos from Flickr could be drag/dropped into GMail) but it gives greater control over where my data is stored. At the moment Google decides where my GMail mailbox lives, and I have to live with the consequences, including the local laws governing police/government access. A more universal means of coupling data to applications (ala files/file systems) would be one step towards allowing physical relocation of my GMail mailbox to a more local/favourable server. After all, does it really matter where by mail lives, so long as the GMail application can still read it and show adverts when I view it?

The answers we seek may already be being implemented in disparate projects and applications. We need to bring them together under a single unified roof — a recognised foundation onto which RIA developers can confidently build. Sure, as these are all 'operating system' type issues we could just leave it up to the likes of Microsoft to decide how to proceed...

...or, we could just seize the initiative ourselves (...?) :)