[Kde-pim] Review Request 109265: Store collection paths instead of collection ids in filter configuration. Part 2/2

Kevin Krammer krammer at kde.org
Sun Mar 3 17:45:30 GMT 2013



> On March 3, 2013, 5:35 p.m., Kevin Krammer wrote:
> > mailcommon/filter/filteractionwithfolder.cpp, line 108
> > <http://git.reviewboard.kde.org/r/109265/diff/1/?file=116722#file116722line108>
> >
> >     if this is the only code where this truely blocking call is needed, maybe the thread should be here intead of the library
> 
> Andras Mantia wrote:
>     Although this is true, I'd keep in the lib as that anyway is private and I see some further usage (in the mail archiver code that Laurent wrote).

The problem is that this is a hack since it hides that this should be done asynchronously.
The library, even private portions, should not encourage blocking usage of asynchronous APIs. Any developer encountering such a situation should need to evaluate if fixing this properly is viable instead


- Kevin


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


On March 3, 2013, 5:40 p.m., Andras Mantia wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/109265/
> -----------------------------------------------------------
> 
> (Updated March 3, 2013, 5:40 p.m.)
> 
> 
> Review request for KDEPIM, Laurent Montel and Volker Krause.
> 
> 
> Description
> -------
> 
> Currently the filter configuration contains a collection id. This id is specific to a single akonadi instance, thus making impossible to synchronize the configuration file between computers and also invalidates all the filters in case of Akonadi database corruption and recreation.
> The patch:
> - extends Util::fullCollectionPath to operate on real names if requested (needed, as otherwise we can't get back the collection id from a path)
> - changes the filter action with folder type filter action (;)) to return the path and adds code path so they can read both ids and paths from the config files
> - uses "export" flag when saving the filter config file, so actually the argsAsRealString() is called on the actions, not argsAsString(). 
> This could be debatable, I could also change argsAsString() to return the path instead. Sincerely I don't see why we need different code path for exporting...
> 
> 
> Diffs
> -----
> 
>   mailcommon/filter/filteractionwithfolder.h 46ee8e7 
>   mailcommon/filter/filteractionwithfolder.cpp 0795c30 
>   mailcommon/filter/filtermanager.cpp bfa8246 
>   mailcommon/mailutil.h 5441b9f 
>   mailcommon/mailutil.cpp 67e0645 
> 
> Diff: http://git.reviewboard.kde.org/r/109265/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Andras Mantia
> 
>

_______________________________________________
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/



More information about the kde-pim mailing list