On 27.5.2004, at 02:31, Geo Carncross wrote:
I've thought about something similiar before, but I've mostly just thought about performance and complexity issues with it. Creating a single view from many mailboxes could be slow without some special indexing.
It shouldn't be slower than performing the actions manually.
Sure, it's not, but clients aren't doing this manually now. Doing it in a simple way would be easy I guess, but I'm not sure if the performance would be good enough to be acceptable.. Especially if a view consists of tens of mailboxes. Each synchronization would require scanning through changes in all of them.
I had been thinking about making some global index about mailboxes and their states. So that by just reading one file would be able to tell what mailboxes have changed. With that kind of system it would work much better.
The only "tricky" part would be the UIDL/ID matchups. If one is willing to implement 64-bit integers, or accept a 2^32 maximal limit on the number of messages accessible in a view, then the problem can be reduced to m=n*nfol+folnum where nfol is the number of subscribed folders, folnum is the relay counter, n is the original UIDL or ID number, and m is the resulting UIDL/ID passed to the client.
IMAP spec only allows using 32bit numbers, so UIDs and message counts can be max. 2^32-1. But I don't think the UID lookup is too difficult, I could just create a new index of uid => {original mailbox id, uid} mapping with simple increasing UIDs.