Future Ideas wiki page

[David Lang]

On Wed, 13 Jan 2010, Bron Gondwana wrote:

> 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?

I thought that there was mention in your list of addressing folders by UID for 
replication purposes.

> 2: how do "ranges" work?

a range within a folder works as-is, a range with different folders is an error

> 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.

> 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.

David Lang

> Bron ( yes, I have been tempted to write something that talks sync_client protocol,
>        why do you ask ;)
>