--===============2105102471==
Content-type: multipart/signed; boundary=nextPart2466431.JI6Bsg7PUQ;
 protocol="application/pgp-signature"; micalg=pgp-sha1
Content-transfer-encoding: 7bit

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

On Sunday 09 September 2007 15:22, Kevin Krammer wrote:
> Hi Tobias,
>
> On Sunday 09 September 2007, Tobias Koenig wrote:
> > On Sat, Sep 08, 2007 at 08:55:10PM +0200, Kevin Krammer wrote:
> > > Are there other type of distribution lists than email? E.g. for
> > > snail mail or shipment?
> >
> > Well, that would be a distribution list with only contact
> > references in it. So any application can load such a list, find the
> > contacts which are referenced there, and extract the address or
> > telephone field.
>
> Hmm.
> If there is a need for specifying the email address, wouldn't there
> also be a need to specify which address or which telephone number to
> use since there can also be more than one?
>
> Maybe we should do an abstract base class for distribution list and
> for now one implementation for emails?

How would a distribution list used with the telephone work? Make a=20
conference call? Anyway, the custom field could be used for this. It is=20
anyway up to the application using the distribution list to make sense=20
of the content of the custom field.

If we want to make it really flexible there needs to be a custom field=20
map.

And in order to find out what is needed for a snail-mail distribution=20
list I'd talk to the KOffice developers since KOffice will be the=20
application used to create serial letters.


And instead of=20
> > =A0 if it is from type contact, it provides
> > =A0 =A0 - name
> > =A0 =A0 - email address
> > =A0 =A0 - custom fields

full contact information should be supported. OTOH, if we do not need=20
this to work without Akonadi then we can easily store all those=20
contacts that are not stored in the user's address books in a special=20
shadow address book and only use contact references. The latter=20
together with making "preferred email" an entry in the custom field map=20
would make the distribution lists truly generic. Of course, the=20
groupware server connector would still have to add the information from=20
the shadow address book to distribution lists that are uploaded to the=20
server, but that's an implementation detail of the connector.


> > > > Distribution lists inside distribution lists are strange and
> > > > I'd like to avoid them. They make stuff unecessarily complex.
> > >
> > > You're the expert :)
> >
> > No, just a lazy developer ;)
>
> Hehe

(Email) Distribution lists referencing distribution lists are very=20
common and would greatly simplify the maintenance of a large number of=20
distribution lists. I'd prefer if this was supported.


Regards,
Ingo

--nextPart2466431.JI6Bsg7PUQ
Content-Type: application/pgp-signature

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

iD8DBQBG5DurGnR+RTDgudgRAt7HAJ0YJT3d22BVYQ8UqCkGF0gTUd+CtQCfRI/v
Llq1dT4gDwTZzOrhUZkCMG0=
=Bs3k
-----END PGP SIGNATURE-----

--nextPart2466431.JI6Bsg7PUQ--

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