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

[Aaron J. Seigo]

On Thursday, December 18, 2014 21.38:18 Sandro Knauß wrote:
> 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.

Yes, I agree that this is a minimum thing that preprocessors need to 
advertise.

> Yes we could, but maybe the user wnats these kinds of aditional header in
> his mail.

For another discussion another day, I think that modifying emails in this 
fashion so that there is a different version in the source than locally is sth 
we should try to avoid.

But as a general concept of "preprocessor modifies the entity in some way", 
your argument is correct imho.

> 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).

since you mentioned moving: the resource will need to provide access to such 
things, since what "move" means is likely to be specific to the source in 
question, and it would be fantastic to have generic preprocessors as much as 
possible. I've been thinking about how to do provide this functionality so 
that it produces as little extra code in the resource (preferably zero, as it 
already knows how to do things like moves), doesn't complicate preprocessors 
and adds as little complexity to the pipeline code.

I've been thinking about how to use commands, the same thing clients use, to 
allow preprocessors to drive the resource. The only wrinkle is that these 
commands should not restart the entire pipeline again. It's not immediately 
evident to me how best to do this, but with a bit more thinking on it an 
elegant solution ought to appear :)

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

well, hopefully this can be calculated rather than need to be explicitly 
configured.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20141219/99af3718/attachment.sig>
-------------- next part --------------
_______________________________________________
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/