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
--
Systems Architect, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com
pgp: 9342 BF08
_______________________________________________
Roundcube Development discussion mailing list
[email protected]
http://lists.roundcube.net/mailman/listinfo/dev
