Web browsers' bookmark support is almost worthless, being designed for bookmarking just one or two sites, not to contain a whole bookshelf of interesting and useful sites encountered. I have therefore in the recent months been experimenting with one of the Web bookmarking services for select casual bookmarks that should not cause a huge threat to privacy, as they offer something a bit more akin to the bookshelf I have envisioned. I have never been a fan of such applications as Web services, and I can't say I have become one. Quite on the contrary.

Web application and server-side computing proponents live in a dreamworld of servers that toil without end, never crashing; of omniscient routers that never make an error, throwing packages like a breeze to their destinations; a dreamworld devoid of crazy excavator operators. Applications designed for such a dreamworld are fundamentally broken in this world I experience, and can not be fixed, as their assumptions do not hold.

The Internet (minus DNS) was purportedly designed to have “intelligence at the edges” rather than control in the middle. Then there can be no single point of failure. The Web application and server-side computing approach, even when implemented on top of such a decentralised network, is an example of the opposite centralised design with control/intelligence at the centre, and inept clients at the edges, when the central server or the route to it fails, which they frequently do.

Frequently needed important applications must not demand access to a central server: intelligence must be brought back to the edges, to the clients. But there is one problem: the clients may not be able to connect to each other, being behind firewalls or not turned on. One great advantage provided by the bookmarking Web applications over browsers' own bookmarks, is that the same data is available from any computer you use. This should not be completely lost. What is needed is a synchronisation service: to keep the intelligence at the edges, and use a dumb server or distributed storage mechanism to store the data fragments – encrypted, of course – that have not been propagated to all your usual access points yet. Then no client is dependent on the service being available, but can use it when it is. But who would provide such a service, if they can't well serve ads as on Web pages?

The nice thing is that any email service with somewhat complete IMAP support should do: full IMAP essentially provides remote file system access operations, so you can add new files and directories, access their contents, delete them, and so on. Very dumb, and good enough for storing new bookmarks and other small fragments of data to be synchronised, as well the information needed to know which fragments have already propagated to every known destination. In fact, email itself demands similar synchronisation protocols, so that both sent and received email to multiple addresses/mailboxes can be stored on one or more computers with automatic removal from IMAP when synchronised and marked as having been dealt with (not same as read). Furthermore, with IMAP as the dumb fragment storage service, it is possible to send new fragments as specially formed emails as well, so you wouldn't need to enter your IMAP password on just every computer used to simply add new information. Email could also be used to share this information; to add/propose bookmarks to friends or so.

Synchronisation actually has quite a bit in common with version control, and therefore the fragments to be synchronised could in some cases simply be patches of a properly distributed version control system. Also, some clients might want to see the data through a different lens, and not download or even provide all of it, such as the web page itself stored in a bookshelf. This latter arrangement begins to ask for servers with a bit more understanding of the (tree) structure of the data, than IMAP. Encryption also becomes more cumbersome, having to be done for partial contents at a time. But perhaps it suffices to just provide metadata and data (the stored page) separately on the server level. For this IMAP should still suffice.

Die, Web applications, die! Long live IMAP applications?