[Kde-pim] Review Request 111720: Partial implementation of CONDSTORE IMAP extension (RFC4551)

[Dan Vrátil]

> On Aug. 2, 2013, 12:22 a.m., Jan Kundrát wrote:
> > kimap/fetchjob.h, line 164
> > <http://git.reviewboard.kde.org/r/111720/diff/3/?file=173933#file173933line164>
> >
> >     RFC4551 says that it's an unsigned 64bit integer. I'd suggest going with "0" as a special value, not -1, and adapting the data type everywhere.

Good point, I've missed the "unsigned" word in specs


On Aug. 2, 2013, 12:22 a.m., Dan Vrátil wrote:
> > Please note that you have to enable CONDSTORE before you make use of it; it's done either via "tag ENABLE CONDSTORE" or via the CONDSTORE parameter to SELECT.
> > 
> > Some servers (Dovecot, for example) do not keep track of MODSEQs until any client enables that extension for the first time; this mens that someone who only uses KMail will not benefit from CONDSTORE on such setups.

I was not aware of that (and it does not seem to be clearly stated in the RFC). I will update KIMAP library and the IMAP resource to take this into account.

 Thanks for pointing this out.


- Dan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/111720/#review36945
-----------------------------------------------------------


On July 29, 2013, 3:17 p.m., Dan Vrátil wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/111720/
> -----------------------------------------------------------
> 
> (Updated July 29, 2013, 3:17 p.m.)
> 
> 
> Review request for KDEPIM-Libraries.
> 
> 
> Description
> -------
> 
> This patch adds partial support for CONDSTORE IMAP extension for fast flags change synchronization, specifically parts 3.1.1 (HIGHESTMODSEQ in SELECT reply) and 3.3.1 (CHANGEDSINCE parameter in FETCH command).
> 
> Parts 3.1.2 and 3.3.2 (NOMODSEQ) are omitted, because their support is not necessary thanks to current KIMAP design
> Part 3.2 (CONDSTORE in STORE command) is omitted because it seems to be too complicated to implement with current KIMAP design and given we don't even need to use it...
> Part 3.4 (MODSEQ in SEARCH command) is omitted because we don't actually use or support SEARCH with Akonadi (not yet, at least)
> Part 3.7 (CONDSTORE in SELECT command) is omitted because it makes no sense in relation to current KIMAP design
> 
> 
> Diffs
> -----
> 
>   kimap/fetchjob.h 75fe6b6 
>   kimap/fetchjob.cpp 3a94e02 
>   kimap/selectjob.h 87157b5 
>   kimap/selectjob.cpp 7854758 
>   kimap/tests/fetchjobtest.cpp 0d97ba1 
>   kimap/tests/selectjobtest.cpp f0b7185 
> 
> Diff: http://git.reviewboard.kde.org/r/111720/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Dan Vrátil
> 
>

_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/