[Kde-pim] akonadinext update: entity processing pipelines in resources

[Sandro Knauß]

Hey,

> I don't think we need to add mail specifics to the filters, something like
> this should be enough:

yes for sure no mail specific parts inside the design. But at least make sure 
that, preprocessors can express if they change the data or not. Because if 
every preprocessor, that changes data is done, the client can get the 
notification. All not changing preprocessors can run afterwards (full text 
search, extracting attachments,...)

>We could also add a filter that runs the spam detection, but then throws the  
modified mail away, only extracting the flags we need. Unless there is a 
reason we do want this as actual headers in the mail.

Yes we could, but maybe the user wnats these kinds of aditional header in his 
mail. The point is here that there is not that easy "chain" to process

* depending on the spam level I want to move mails around
* depending on the spam level mark the mail as read / as junk 

if now run all moving filters all before the spamdetection preprocessor, this 
one also needs to implement the moving logic (doubling code sucks).

In the end the user must have the possibility to define it own chain of 
preprocessors (for moving and chaninging preprocessors). 

All non changing preprocessors are safe to run in parallel and or after the 
client is informed about this niew content.

Regads,

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