On Wed, 13 Jan 2010, Bron Gondwana wrote: > On Wed, 13 Jan 2010 16:26 -0800, "David Lang" <david.lang@xxxxxxxxxxxxxxxxxx> wrote: >> On Sat, 9 Jan 2010, Bron Gondwana wrote: >> >>> On Sat, 09 Jan 2010 15:10 +0100, "Alexey Melnikov" <alexey.melnikov@xxxxxxxxx> 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 ;) > ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
