git master branch going unstable

[Ken Murchison]

Bron,

You and Greg might want to discuss your idea(s) with the MORG WG.  They 
have been working on similar things for a while and might be able to 
give you some direction, or at least steer you away from things that 
they have deemed as bad.

http://datatracker.ietf.org/wg/morg/charter/


Bron Gondwana wrote:
> (I hope you don't mind me CC'ing this back to the list so everyone
> can read it!)
> 
> On Tue, Jan 11, 2011 at 04:58:06PM +0000, Alexey Melnikov wrote:
>> Hi Bron,
>>
>> Bron Gondwana wrote:
>>
>>> Actually - it's been unstable for a few days now since I added the
>>> "specialuse" patches
>>>
>> I meant to ask earlier: is there a public list of things that you
>> are planning in 2.5? In particular I am interested in knowing which
>> IMAP extensions you and your co-workers are planning to add.
> 
> We should really discuss them on cyrus-devel and the IRC channel.
> We've been quite lax about that :(
> 
> Do you have any particular extentions you're interested in?  
>  
>>> * conversations (cross folder thread) initial support from Greg
>> Do you have a pointer to how this works/what does this do?
> 
> No - we'll have to write something up on this.  It's going to be
> a non-standard extention to start off with.  Hopefully once we've
> ironed out the details we can write an RFC.
> 
> Basically it (Greg, correct me if I've messed anything up here...):
> 
> *) adds a 64 bit "cid" (conversation id) to each index record.
> *) adds a separate database (per user) which contains a map of
>    message-id header to cid.
> *) for each appended message, gets every "message-id" from the
>    message header (Message-Id, In-Reply-To, References) and looks
>    them up in the conversations database.
> *) if a related message is found, it keeps the same cid.  If
>    no related message is found, it allocates a "random" cid
>    (first 64 bits of the sha1 of the current message in fact)
> *) SPECIAL CASE: if TWO SEPARATE cids are found then we have
>    a message which links two previously separate conversations.
>    In this case, bias upwards - choose the higher cid and re-number
>    all the messages with the lower cid.
>    (the same renumbering logic will be used by replication to merge
>     different cids from different ends)
> 
> There's a bit more magic to do with remembering which folders
> are "touched" by each conversation to make the implementation more
> efficient.  And of course making reconstruct work, and able to
> repair a damaged conversations database.
> 
> .....
> 
> We're about here now.  The next step is defining a good interface to
> access this data :)  
> 
> In particular, there's a few things we need:
> 
>>From Folder/UidValidity/Uid triplet - get a conversation ID.
> 
>>From a triplet or a conversation ID - get a list of all "related"
> messages (those with the same conversation ID) across ALL folders
> belonging to the same user.
> 
> SEARCH - within a conversation
> SORT - within a conversation
> 
> .....
> 
> Kind of somewhat separately, we want some form of sorted search
> windowing... where you can say "give me the first 10 messages which
> match this search within this sort - and it will sort the messages
> (efficient) first and then apply the search (usually more expensive)
> to each message until it's found enough matches - then return!
> 
> At the moment it always searches first, then sorts the search results,
> which can be very expensive for a body search across all folders - 
> which is what customers often want, funnily enough.
> 
> Bron.
> 


-- 
Kenneth Murchison
Principle Systems Software Engineer
Carnegie Mellon University