Now blogging at diego's weblog. See you over there!

on IMAP and sync

(As far as I know) IMAP was supposed to be a "solution" for multiple access to the same mailbox. The idea was that people would be able to leave their folders in the server and access them remotely, possibly doing some replication for offline work (i.e., not all email clients support this).

Server-side storage has the advantage of being accessible from anywhere, but it also has disadvantages. One of them is that disconnected use is often cumbersome (since the program's UI is built around the idea that the folder is actually on the server--witness Outlook's horrific solution of placing the IMAP hierarchy separate from the standard folder hierarchy in a completely different structure), and it places a heavy load on the connection. Another problem is that since the program is dealing with the data "living" on the server, it suddenly has to deal with connections between data in two formats, so certain things that would be possible with just a local database now are not. Extensive connections between objects is one example (for example, maintaining a correlation in the program's store between, for example, a Contact and all the mail Messages received from that contact. Those correlations make some operations (e.g., search) fast, and they give the application the potential to do automatic organization of information (instead of having to find correlations via "brute-force" text parsing methods, such as something like Google might do). It's a question of using the context that is there, or ignoring it.

So, with spaces, the approach I chose was not to allow IMAP "connected mode". This means that, as far as spaces is concerned, IMAP is just another data source to be synchronized with. The key word here is "synchronized."

A POP store functions basically in a store-and-retrieve fashion. It is not assumed to be the central storage. An IMAP store is meant to be a repository that has "authoritative information" about your data. However, in these days we synchronize our data with many devices, handhelds, network storage, other machines. So does it really make sense to assume that a server somewhere is the central repository? Rephrasing that: isn't it more logical to assume that we have several "devices" that contain our information and we'd like our programs to synchronize seamlessly and integrate it transparently under a single "information tree"? (so giving us the nice side effect of keeping multiple backups)

My answer for this question is: yes.

What I was wondering was, is there any use-scenario where this won't work at all? Where online sync would be required? mmm....

Categories: technology
Posted by diego on November 5, 2002 at 11:46 PM

zero-install platforms

Don mentions that we need zero-install platforms for net-delivery of code:

The Net needs zero-install extensible client platforms. Java WebStart and .NET meets some of the needs, but both require the user to install 6 to 20 megabytes of mostly unused code and lacks the ability to incrementally update and extend the platform
I couldn't agree more. I have previously commented on the need for Java in particular to streamline its installation process, and the same applies to other platforms (such as .Net). As long as Internet-based installation of software is a hassle, it will be difficult to break the control that Microsoft has through OEMs and such.

Categories: technology
Posted by diego on November 5, 2002 at 12:56 AM

Copyright © Diego Doval 2002-2011.