[Kde-pim] kabc/distributionlist: Entry class returns references

[Kevin Krammer]

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 
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 
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 extension 
to KABC::Resource?

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20070908/635072e5/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/