Future Ideas wiki page

[Bron Gondwana]

On Wed, 13 Jan 2010 17:40 -0800, "David Lang" <david.lang at digitalinsight.com> wrote:
> > Absolutely - two issues.
> >
> > 1: how to you give folders UIDs?
> 
> I thought that there was mention in your list of addressing folders by
> UID for 
> replication purposes.

UniqueID - it's an internal 16 hex digit field.  Tacking one of those on every
result item would be expensive for bandwidth.

> > 2: how do "ranges" work?
> 
> a range within a folder works as-is, a range with different folders is an
> error

I guess so.

> > The first one is the killer, because you'd have to be able to map back to select
> > by UID as well.  SELECT 195455, or something.
> >
> > Actually, the whole "SELECTED" idea would probably be discarded, instead just
> > addressing everything by UID and never actually selecting folders.
> 
> yes, for some things this is extremely useful for others it's just added 
> complication.

There's not much that it's useful for with cross folder work!

Internally our web interface actually already does exactly what you describe so it
can support cross folder searching.  Every UnqMsg is <folderid>:<uid>, where
FolderId is a reference to a database field which contains a mapping to the
underlying folder.  We also store a bunch of metadata about how to present that
particular folder to the user (number of messages to display, type of preview,
default sort, etc)

> > By which time, why not just define a brand new protocol not called IMAP which
> > includes the good bits of what IMAP currently does, and discards anything that
> > doesn't fit the multi-folder worldview.  So long as you made the storage and
> > meta-data requirements compatible with already existing Cyrus and other IMAP
> > servers, you could just write a whole new daemon that talked your new protocol
> > and be happy with that.
> 
> you could, but just like not every client uses UIDs and still use message 
> numbers, this is being done in a backwards compatible manner so that the
> client 
> can use either one, and a server can support both.

The problem is you keep paying a higher and higher complexity cost at the server end.
Once you start talking not having a folder selected, that cost (and associated
locking issues) is going to blow your implementation complexity way up.  Cross folder is
far enough away from the initial design of IMAP that the impedance mismatch is grating
pretty badly!
-- 
  Bron Gondwana
  brong at fastmail.fm