Future Ideas wiki page

[Bron Gondwana]

On Wed, 13 Jan 2010 16:26 -0800, "David Lang" <david.lang at digitalinsight.com> wrote:
> On Sat, 9 Jan 2010, Bron Gondwana wrote:
> 
> > On Sat, 09 Jan 2010 15:10 +0100, "Alexey Melnikov" <alexey.melnikov at isode.com> wrote:
> >> Bron Gondwana wrote:
> >>> While we're at it, I'm much more interested in cross-folder searching with sort
> >>> order that doesn't require folder as the first item, but that's significantly more
> >>> complex!
> >>>
> >>>
> >> <http://tools.ietf.org/html/draft-ietf-morg-multimailbox-search-01>?
> >> If you have some additional use cases in mind, please let me know.
> >
> > "with sort order that doesn't require folder as the first item".  I guess you could return
> > multiple ESEARCH responses with the same folder mentioned to get the ordering...
> >
> > It's still more folder-centric than otherwise, and it's going to make following threads
> > across folders (say INBOX and a couple of time based archive folders) tricky!
> 
> thinking about this a bit more, it sounds almost like what you are
> wanting is a 
> third mode of addressing messages.
> 
> currently we can do
> 
> message # in this folder
> 
> messageUID in this folder
> 
> and something like folderUID:messageUID would open up what you are
> looking for 
> (probably plus more)
> 
> Would it be possible to take a character that can't appear in a message#
> or UID 
> position in the existing protocol and define it as a delimiter for this?
> (I used 
> ':' in my example above as I believe that '-' is used to indicate a range
> of 
> messages)
> 
> If it is, then this would 'just' be a new addressing option like UID
> currently 
> is, and like UID, clients would opt-in to this new mode. (it would still
> need a 
> RFC for the new mode, but does this sound like a solution to what you are 
> looking for?

Absolutely - two issues.

1: how to you give folders UIDs?
2: how do "ranges" work?

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.

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.

Bron ( yes, I have been tempted to write something that talks sync_client protocol,
        why do you ask ;)
-- 
  Bron Gondwana
  brong at fastmail.fm