--===============0591735414==
Content-Type: multipart/signed;
  boundary="nextPart2671528.nrPRflBKWv";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart2671528.nrPRflBKWv
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Tobias,

On Saturday 08 September 2007, Tobias Koenig wrote:
> Every groupware uses it's own way of handling distribution lists, so I
> can't see a way to find a common standard here.
>
> Besides we have to differ between 'How distribution lists appear to the
> outside' and 'How to handle them in KDE'.
>
> The first one is a task of the Akonadi agents, which have to convert the
> distribution lists (as same as the contacts itself) into a special
> format, which the groupware server they talk to understands.

Sounds like the correct approach.

> So what we really have to do is to find a common format how to store
> distribution lists in Akonadi and how to access them from C++ (which
> means finding an API).
>
> Storing them in Akonadi should be done by storing an XML document, maybe
> finding a common standard here.

I guess it would be possible to support more than one format here, so I don=
't=20
think we lose anything if we start with an own one.

> This format should support the following distribution list attributes:
>
>   - unique identifier
>   - user visible i18n'ed name
>   - list of entries
>   - custom fields
>
> The entries should have the following attributes:
>
>   - type (contact, contact reference)
>
>   if it is from type contact, it provides
>     - name
>     - email address
>     - custom fields
>
>   if it is from type contact reference, it contains
>
>     - contact uid
>     - preferred email
>     - custom fields

Are there other type of distribution lists than email? E.g. for snail mail =
or=20
shipment?

> Distribution lists inside distribution lists are strange and I'd like to
> avoid them. They make stuff unecessarily complex.

You're the expert :)

> Now we come to the KDE side. There we need a C++ class to handle
> distribution lists. In libkabc they are two completely different
> classes, however David Faure provided a hack (KPIM::DistributionLists),
> which allows to store distribution lists _inside_ an Addressee object.
>
> This was done to be able to provide resource specific distribution
> lists.
>
> For KDE 4 I'd prefer two separated classes again, however this time the
> resource api (of course only until Akonadi is in place) will provide
> methods for accessing distribution lists as well.
>
> So we can retire KABC::DistributionListManager and let the single
> KResources load/store the distribution lists.

Are we talking about a special KRES::Resource subclass or about an extensio=
n=20
to KABC::Resource?

Cheers,
Kevin

=2D-=20
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBG4vAcnKMhG6pzZJIRAkV8AJ9t/JzZGoTuVKeA+3KOyTdrfI7WSgCdHNRY
VxKfgGIGt0SjNQPRTfIMBp4=
=QoBo
-----END PGP SIGNATURE-----

--nextPart2671528.nrPRflBKWv--

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