From kde-pim  Sun Mar 28 22:03:04 2010
From: Ingo =?iso-8859-15?q?Kl=F6cker?= <kloecker () kde ! org>
Date: Sun, 28 Mar 2010 22:03:04 +0000
To: kde-pim
Subject: Re: [Kde-pim]
Message-Id: <201003290003.05452 () thufir ! ingo-kloecker ! de>
X-MARC-Message: https://marc.info/?l=kde-pim&m=126981384301144
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============1768476104=="

--===============1768476104==
Content-type: multipart/signed; boundary=nextPart11471070.77Et9bj0YZ;
 protocol="application/pgp-signature"; micalg=pgp-sha1
Content-transfer-encoding: 7bit

--nextPart11471070.77Et9bj0YZ
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable

On Sunday 28 March 2010, Kevin Krammer wrote:
> On Sunday, 2010-03-28, Maciek Zarzycki wrote:
> > Hi,
> >=20
> > I have reread all posts in this thread and I would like to
> > summarize it a
> >=20
> >  bit and propose my solution. Any comments from you are more than
> >  welcome
> > =20
> >  :).
> >=20
> > The main idea behind this project is to create a unified
> > import/export
> >=20
> >  dialog for all KDE PIM applications (and perhaps some others).
> >  This
> >=20
> >  utility should present following features:
> > * capability of handling various types of data as used in PIM
> > applications * capability of handling configuration files
> > * easily extandible to handle new types of data / applications
> > * user should be able to download new features from 'get hot new
> > stuff'
>=20
> I wouldn't put that down as a kind of requirement. IMHO this is more
> like nice to have or after GSOC stuff.
>=20
> > * as easy to use as possible (some kind of matching presented
> > options with input files / context in which the utility is used)
> >=20
> > The solution fulfilling all the above requirements must be based on
> > a
> >=20
> >  plugin architecture.
>=20
> I'd say that is an implementation option not the only possible
> solution. Wordings like "must be" will have to be defended on basis
> of clearly specified use cases showing that there is on other viable
> way of doing it properly.
>=20
> >  What is more, the plugins for individual actions
> >  should be written in interpreted language to allow easy
> >  installation from 'get hot new stuff' (python or javascript using
> >  QScript). What I plan to do is following.
>=20
> While I agree that scripability or even script language based plugins
> sound like really powerful ways of making the tool flexible and long
> time usable, I am also quite concerned about security implications.
>=20
> A script performing import operations on Akonadi will either have to
> very limited on what itself can do (e.g. only operate on collections
> passed to it by user controlled portions of the app). If the plugin
> can decide where to put e.g. emails it could decide to put them into
> the system's outbox, making it a perfect spam tool.
> (it could do the user chosen import on the side to make this less
> obvious, trojan style)

GHNS would only provide plugins which have been checked by us. AFAIK,=20
GHNS does even support signing the 'hot new stuff' nowadays.


Regards,
Ingo

--nextPart11471070.77Et9bj0YZ
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

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

iEYEABECAAYFAkuv0hkACgkQGnR+RTDgudhx3QCg0de8tRk6QO+1Pw2e0f+ugurl
fYEAoNUa+MadFgRANkNMNQBgo2ZjQd7J
=q3lI
-----END PGP SIGNATURE-----

--nextPart11471070.77Et9bj0YZ--

--===============1768476104==
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/
--===============1768476104==--