Friday, 30 October 2009

Farewell, desktop? Different strategies

Although I used to use my PC for my business, which required some specialised software, mostly my needs aren't that much different from everyone else: web browsing, email, documents, spreadsheets, news feeds, digital music - though I do also do a lot of web development, which requires its own development and server software.

Up until recently, like most people, I've been doing all this on my desktop PC. An obvious disadvantage to a desktop is that it's tied to one place; laptops and their various derivatives like netbooks remove this to some extent, as you can carry your data around with you, but inevitably there are situations where you cannot take your laptop/netbook and have to use another device. If you have data on some other device, such as a mobile phone, you have to do regular synchronisation with your desktop/laptop. Another disadvantage is that your data will be lost if you have a disk crash or if your computer is stolen. The traditional way of combating the latter problem is to make regular backups. USB sticks nowadays provide quite large storage capacities for little cost, and are the obvious solution for audio files and the like which don't change and don't have to be synchronised. An alternative is online storage - I use Humyo - as an offsite backup. This has the advantage that files can be shared, but I find it less convincing for large items like audio files which take up a lot of bandwidth to transmit to and fro. It also only addresses the question of data, not the programs needed to create/maintain/view/listen to that data.

For that you need software, and as with online backup of data a growing alternative to desktop software is web software. This means there are 3 basic strategies:
  1. data and software both on the local machine, be that desktop or laptop, mobile phone or whatever other gadgets manufacturers come up with
  2. data and software both on the web
  3. data on the web; software local
[In theory, there is another alternative - data local, software on the web - but I never heard of anyone implementing that!]

(1) is the traditional way. Google is the best-known exponent of (2), with applications such as Google Mail and Google Docs. It has the great advantage that Google looks after all the server infrastructure and programs; it's also free. One obvious disadvantage is the need to still use the data when there is no network link. Google offers Gears to get round this problem, and the storage abilities of HTML5 will probably replace this eventually.

There is also the security/privacy aspect: do I really want Google having responsibility for all my private correspondence? Although Google is unlikely to go bust in the foreseeable future, and is unlikely to abandon its Mail and Docs services either, there is also the problem that I have no control over what features or facilities they allow or introduce in the future. For someone used to the open-source way of doing things, where you can change any program you want whenever you want, this might be problematic.

There are plenty of alternatives to Google, the most extreme being to use one of the 'webtop' or 'web desktop' systems. These provide a pseudo-desktop on the web, giving you file space and a series of desktop-style applications. There is a list of these on Wikipedia and, like Google, they give you a central repository for your data, which you can access from anywhere. They cover a much wider range of software than Google, though, aiming to completely replace the desktop. However, they suffer the same disadvantages of tying you to someone else's vision, and many of them being start-ups without much obvious income, it's questionable how viable they are. Several have already disappeared.

One of the more interesting ones is the rather bizarrely-named G.ho.st, which runs under Flash; it's interesting as much for being a joint Israeli-Palestinian venture as for its software, about the only software company I might support for political reasons. It also includes the ability to access data on other servers, such as Google's, so you can store other material on G.ho.st, but still store your mail or docs on Google and access them through G.ho.st.

An interesting attempt to address the issue of non-viable business models is eyeOS, an open-source system in PHP/AJAX which you can download and run on your own PHP-capable server. This gives you a central repository but also means you can install and run, or change, any modules you like, resolving the "tied-to-someone-else's-vision" problem. However, you are then back with the problem of maintaining the installation and paying for the server infrastructure. eyeOS points out that you can also install the software on your own PC, but that seems to me to be missing the point!

Another system worth mentioning is OpenGoo, though this is geared to collaborative working, so is oriented to small companies and organisations rather than individuals.

Wikipedia's page lists speed as one of the disadvantages of this technology. This would certainly be the case with the webtops, which are slow to use. However, Google seem to have found a solution to this, as I have not found using Google Mail or Docs instead of desktops to be noticeably slower, at least on a reasonably capable broadband connection.

Google's total vision, though, is rather different from the webtop. It's proposing replacing the desktop operating system with its own cut-down version, which according to the sketchy details so far, will be based on a browser and probably not much else. So all the data would be on the web, and all the software would be browser-based, and heavily oriented to AJAX and similar web-service technologies. Like many other people, I look forward to hearing more details of this.

Meanwhile, back at KDE, their vision, as is emerging from their Project Silk, is closer to option (3). The browser, and HTTP in general, is not an ideal way of processing data. It's oriented to pages which are read, not to reading or changing discrete chunks of data. It also has no state, i.e. the server treats each page request separately, so there is no concept of a transaction comprising more than one request. To some extent, AJAX gets round this, and there are various projects to improve the basics of web applications, but it's still essentially mis-using the web. So, even if data is stored on the web, it can still be better to adapt existing desktop programs to read and process it. As long as there's a standard way of accessing data over HTTP - an API - an application, wherever it might be, can treat it just like a local file, so it doesn't really matter to the application whether a chunk of data is coming from a local or remote source. This is a basic insight that KDE has always had; Konqueror has never cared whether files are local or accessed via ftp or even secure ftp, or whether an html file is local or accessed via HTTP - it displays them in the same way, and in the case of files, can even edit them in the same way too. A Google spreadsheet, for example, can be read via an API, even to access a specific cell, so this can be done by any program that knows how to use the API; it does not have to be a spreadsheet or browser program.

The 3 strategies I've listed here are often presented as alternatives, but they don't have to be; in practice, there's no reason why you can't mix or use several at the same time. In fact, if you're using online services, it's better not to limit yourself to one but store your data in several places then, if one of them goes out of business, you just go to the other. So you can have an online backup storage on a specialised site like humyo, have the same documents on a webtop, and also run eyeOS on your own website. Overkill, perhaps, but perfectly possible.

At the moment, I've not come to any firm conclusions from all this, apart from that having competing visions is 'A Good Thing'. I don't find the webtop approach very convincing, particularly for those like me who already have a real desktop. I can see it might have its uses for those who don't have a desktop/laptop of their own, but use other people's, in libraries, netcafes or whatever. Then you can have your own personal desktop without any support hassles or expense. But even here, I find the Google approach more convincing: having individual apps as separate services, only loosely linked. After all, it's the individual services I'm interested in; having them all together in some fake 'desktop' is only important for those who are stuck in that mindset. eyeOS seem to be acknowledging this with their new version, which seems to be moving away from the desktop paradigm.

I'll put my current status in a separate post.

No comments:

Post a Comment