On 2012-03-29 11:00, Ian Lewis wrote:
Hi Jeroen, thanks very much for the comment as my work seems a bit like sailing the unknown at the moment. The Cyrus IMAP "Conversations" are interesting mainly because an email thread search now spans folders. However, as far as I can tell, that development really refers to a THREAD (reply emails with a common parent email), not what I would call a CONVERSATION (emails between two people).
Hi Ian,
I'm sorry, obviously you have given this a lot more thought than I have
- I didn't want to raise any ambiguity in terminology, but I suppose
there's a point in using (among other things, perhaps?) cross-folder threading. Note that the "Conversations" feature in Cyrus IMAP, if I recall correctly, is also supposed to implement cross-folder search capabilities (i.e. search for From/To/CC <contact>?).
I reckon you'll agree, a conversation does not necessarily exist between just two peers. I reckon there may be many parties to a conversation, and perhaps, intuitively, users expect no gaps to exist in a conversation - but you tell me ;-)
So, if I were to select "Lewis, Ian" wanting to see all communications involving "Lewis, Ian", I suppose I want to see the complete thread and not just the messages you sent or the messages I myself or somebody else (with you or me in CC or through a list?) sent to you. I wonder what the conversation(s) would otherwise look like in a UI? A "thread" -as part of one or more conversations- with/without gaps comes to mind, and I suppose there's quite a difference between the two.
In any case, the "Conversations" feature in Cyrus IMAP isn't finalized. It needs an RFC draft still, and then the server-side implementation needs to be brought up to par with the actual proposed definition of the protocol extension. I *suppose* this could be a very interesting endeavour for you to participate in, and I'm confident you'd bring an insightful, valuable perspective to the entire process.
Admittedly, I don't think work on the definition has even started yet. While this means there's quite a lot of work to do, I suppose it also means there's more flexibility as to what the protocol extension definition ultimately ends up looking like.
Hence, I figured I'd give you a nudge ;-)
Kind regards,
Jeroen van Meeuwen