Mainly web clients, installed clients usually implements
threading internally to overcome problems with the original
references algorithm that is often confusing.
The problem with references is that it includes subject
grouping, that is an old netscape model of the 90s: today, we
just need references within the headers ids, or we may take a
wrong message in the thread just because it has a similar
subject (for example automatic mails with same subjects would be
treated as a thread, which is wrong).
Now, we're staring to implement threading view on our web
collaboration software, running on cyrus.
So we are investigating how RoundCube is doing threading on a
dovecot installation, and we found it to be the same as the
client algrithm of Thunderbird, which is fine. Looking at the
protocol, it uses REFS first, probably because it has no subject
grouping by definition, and it should have a better date
sorting. Should, because I found that Dovecot does not sort it
reversed...
Maybe I will ask Dovecot guys why they choose to keep sort same
as references: I suspect that claim to support refs, but
actually the do the same references functions, but never do
subject grouping.
----------------------------------------------------------------------------------------
*Sonicle S.r.l. *: http://www.sonicle.com
*Music: *http://www.gabrielebulfon.com
*Quantum Mechanics : *http://www.cdbaby.com/cd/gabrielebulfon
------------------------------------------------------------------------
*Da:* Ken Murchison <mu...@andrew.cmu.edu>
*A:* gbul...@sonicle.com info-cyrus@lists.andrew.cmu.edu
*Data:* 8 luglio 2016 17.17.32 CEST
*Oggetto:* Re: thread=refs
On 07/08/2016 11:08 AM, Gabriele Bulfon wrote:
Ok, sure, but still two issues remain other than the draft:
- we need to get rid of subject grouping in REFS, it only
brings disorder, merging stuff that is not related
I believe that the parameterization of the core functions
should be able to handle this.
- I would try to guess why dovecot does not change sorting
in REFS, keeping it same as REFERENCES
I would contact that Dovecot authors and find out which
version of the THREAD=REFS draft they based their work on.
BTW, which clients use THREAD=REFS?
----------------------------------------------------------------------------------------
*Sonicle S.r.l. *: http://www.sonicle.com
*Music: *http://www.gabrielebulfon.com
*Quantum Mechanics : *http://www.cdbaby.com/cd/gabrielebulfon
------------------------------------------------------------------------
*Da:* Ken Murchison <mu...@andrew.cmu.edu>
*A:* gbul...@sonicle.com info-cyrus@lists.andrew.cmu.edu
*Data:* 8 luglio 2016 16.39.17 CEST
*Oggetto:* Re: thread=refs
Is there an actual RFC? All I find is
draft-ietf-morg-inthread-01. Looking at that draft, the
only difference between REFS ad REFERENCES is this:
THREAD=REFS sorts threads by the most recent INTERNALDATE in
each
thread, replacing THREAD=REFERENCES step (4). This means that
when a
new message arrives, its thread becomes the latest thread.
(Note
that while threads are sorted by arrival date, messages within
a
thread are sorted by sent date, just as for THREAD=REFERENCES.)
This being the case, I don't think we need two copies
of the threading functions. I'd modify the exiting
functions to take an additional parameter to specify
whether we're doing REFS or REFERENCES and then have 2
wrapper functions which call the main function with the
parameter set appropriately for the given algorithm.
On 07/08/2016 10:03 AM, Gabriele Bulfon wrote:
Ok, it works :) but checking against dovecot
implementation, it looks like they have refs order
same as references, but without subject grouping.
AFAIK the RFC on refs says ordering of dates within
the group should be reversed. Am I wrong?
----------------------------------------------------------------------------------------
*Sonicle S.r.l. *: http://www.sonicle.com
*Music: *http://www.gabrielebulfon.com
*Quantum Mechanics :
*http://www.cdbaby.com/cd/gabrielebulfon
------------------------------------------------------------------------
*Da:* Gabriele Bulfon via Info-cyrus
<info-cyrus@lists.andrew.cmu.edu>
*A:* Ken Murchison <mu...@andrew.cmu.edu>
info-cyrus@lists.andrew.cmu.edu
*Data:* 8 luglio 2016 15.22.56 CEST
*Oggetto:* Re: thread=refs
Testing ;) and checking against a dovecot machine
with refs and same messages.
Will let you know
----------------------------------------------------------------------------------------
*Sonicle S.r.l. *: http://www.sonicle.com
<http://www.sonicle.com/>
*Music: *http://www.gabrielebulfon.com
*Quantum Mechanics :
*http://www.cdbaby.com/cd/gabrielebulfon
------------------------------------------------------------------------
*Da:* Ken Murchison <mu...@andrew.cmu.edu>
*A:* gbul...@sonicle.com
info-cyrus@lists.andrew.cmu.edu
*Data:* 8 luglio 2016 15.02.38 CEST
*Oggetto:* Re: thread=refs
On 07/07/2016 02:03 PM, Gabriele Bulfon via
Info-cyrus wrote:
I can finally get back to this after so many
months!
I checked the sources, and I actually see it
doesn't look very hard.
Looks like:
- renaming all functions like
"index_thread_ref" into "index_thread_references"
- duplicate them as "index_thread_refs"
- let "references" alg call the "references"
funcs
- add support for "refs" in thread_algs and
let them call the "refs" funcs
Makes sense.
then:
- completely remove the call to
"ref_group_subjects", we don't want it at all
in refs
- change the sortcrit to use the SORT_REVERSE
modifier
As long as you mean making these changes for
just the "refs" variant and not both.
what do you think? may be fine?
----------------------------------------------------------------------------------------
*Sonicle S.r.l. *: http://www.sonicle.com
*Music: *http://www.gabrielebulfon.com
*Quantum Mechanics :
*http://www.cdbaby.com/cd/gabrielebulfon
------------------------------------------------------------------------
*Da:* Ken Murchison <mu...@andrew.cmu.edu>
*A:* info-cyrus@lists.andrew.cmu.edu
*Data:* 5 ottobre 2015 14.04.02 CEST
*Oggetto:* Re: thread=refs
As far as I can tell, the last
specification for thread=refs was
here:https://tools.ietf.org/html/draft-ietf-morg-inthread-01
To implement this you want to look at
index.c in the Cyrus source and add
another entry to the thread_algs[] array.
I'm guessing that you can reuse a lot of
the existing index_thread_ref() code
(which is probably needs to be renamed to
index_thread_references()).
On 10/05/2015 06:07 AM, Gabriele Bulfon
wrote:
Great, Ken. Can you give me some advice
/ pointer to the sources I should look at?
Gabriele
------------------------------------------------------------------------
*Da:* Ken Murchison <mu...@andrew.cmu.edu>
*A:* info-cyrus@lists.andrew.cmu.edu
*Data:* 2 ottobre 2015 19.08.04 CEST
*Oggetto:* Re: thread=refs
On 10/02/2015 10:53 AM, Gabriele
Bulfon wrote:
Nice, it's not a big deal for us to
upgrade to new versions, surely
easier than porting to Dovecot! ;)
So, maybe we can help with the
implementation.
In my mind, it's almost about
changing the "thread=reference" and
let it omit the subject matching,
change sorting
and...maybe just this? How much
hard do you think it is?
That sounds about right from what I
remember of THREAD=REFERENCES (which
I co-authored and implemented) and
THREAD=REFS (which I think was last
documented in 2010).
------------------------------------------------------------------------
*Da:* Bron Gondwana <br...@fastmail.fm>
*A:* info-cyrus@lists.andrew.cmu.edu
*Data:* 2 ottobre 2015 12.59.08 CEST
*Oggetto:* Re: thread=refs
No, there isn't. The
conversations work in 3.0 beta
contains a lot of what would be
required to efficiently
implement THREAD=REFS, but
nobody has done the work to
implement it.
It certainly will never be
backported to the 2.4 series,
which is only getting security
updates and fixes for major
bugs now.
Regards,
Bron.
On Fri, Oct 2, 2015, at 18:40,
Gabriele Bulfon wrote:
Hi,
we have systems running cyrus
2.4.12, where thread
algorithms are only references
and orderedsubject.
Is there support for the
thread=refs algorithm?
Thanks
Gabriele
----
Cyrus Home Page:
http://www.cyrusimap.org/
List Archives/Info:
http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
--
Bron Gondwana
br...@fastmail.fm
----
Cyrus Home Page:http://www.cyrusimap.org/
List
Archives/Info:http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
----
Cyrus Home Page:http://www.cyrusimap.org/
List
Archives/Info:http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
----
Cyrus Home Page:http://www.cyrusimap.org/
List
Archives/Info:http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
----
Cyrus Home Page:http://www.cyrusimap.org/
List
Archives/Info:http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
----
Cyrus Home Page:http://www.cyrusimap.org/
List Archives/Info:http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
