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 <http://www.sonicle.com/>
*Music: *http://www.gabrielebulfon.com <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
