From kde-pim  Fri Dec 19 06:03:31 2014
From: "Aaron J. Seigo" <aseigo () kde ! org>
Date: Fri, 19 Dec 2014 06:03:31 +0000
To: kde-pim
Subject: Re: [Kde-pim] akonadinext update: entity processing pipelines in resources
Message-Id: <6510779.xEXkE1OZLi () serenity>
X-MARC-Message: https://marc.info/?l=kde-pim&m=141896912315776
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============7893763298265556169=="


--===============7893763298265556169==
Content-Type: multipart/signed; boundary="nextPart3086462.WlP26DmCee"; micalg="pgp-sha1"; protocol="application/pgp-signature"


--nextPart3086462.WlP26DmCee
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

On Thursday, December 18, 2014 21.38:18 Sandro Knau=DF wrote:
> Hey,
>=20
> > I don't think we need to add mail specifics to the filters, somethi=
ng like
>=20
> > this should be enough:
> yes for sure no mail specific parts inside the design. But at least m=
ake
> 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=20=

advertise.

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

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

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

> The point is here that there is not that easy "chain" to process
>=20
> * depending on the spam level I want to move mails around
> * depending on the spam level mark the mail as read / as junk
>=20
> if now run all moving filters all before the spamdetection preprocess=
or,
> this one also needs to implement the moving logic (doubling code suck=
s).

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

I've been thinking about how to use commands, the same thing clients us=
e, to=20
allow preprocessors to drive the resource. The only wrinkle is that the=
se=20
commands should not restart the entire pipeline again. It's not immedia=
tely=20
evident to me how best to do this, but with a bit more thinking on it a=
n=20
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 explicitl=
y=20
configured.

=2D-=20
Aaron J. Seigo
--nextPart3086462.WlP26DmCee
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEABECAAYFAlSTv7MACgkQ1rcusafx20MzoACfWttfucj7av2Wz4gCri6+Ahdx
EYAAnj8taXzaRSyW9OjgZefRKclimDV/
=pl9D
-----END PGP SIGNATURE-----

--nextPart3086462.WlP26DmCee--


--===============7893763298265556169==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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