|
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?
----------------------------------------------------------------------------------------
Da:
Ken Murchison <murch@xxxxxxxxxxxxxx>
A: gbulfon@xxxxxxxxxxx info-cyrus@xxxxxxxxxxxxxxxxxxxx
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?
----------------------------------------------------------------------------------------
Da:
Gabriele Bulfon via Info-cyrus <info-cyrus@xxxxxxxxxxxxxxxxxxxx>
A: Ken Murchison <murch@xxxxxxxxxxxxxx>
info-cyrus@xxxxxxxxxxxxxxxxxxxx
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
----------------------------------------------------------------------------------------
Da:
Ken Murchison <murch@xxxxxxxxxxxxxx>
A: gbulfon@xxxxxxxxxxx
info-cyrus@xxxxxxxxxxxxxxxxxxxx
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?
----------------------------------------------------------------------------------------
Da: Ken Murchison <murch@xxxxxxxxxxxxxx>
A: info-cyrus@xxxxxxxxxxxxxxxxxxxx
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 <murch@xxxxxxxxxxxxxx>
A: info-cyrus@xxxxxxxxxxxxxxxxxxxx
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 <brong@xxxxxxxxxxx>
A: info-cyrus@xxxxxxxxxxxxxxxxxxxx
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
----
To Unsubscribe:
----
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
|
