[Kolab-devel] distributionlists testing
Gunnar Wrobel
wrobel at pardus.de
Fri Apr 25 08:04:24 CEST 2008
Hi Mike,
Mike Gabriel <m.gabriel at das-netzwerkteam.de> writes:
> hi gunnar,
>
>> What held it up for me was the fact that adding users did not seem to
>> work correctly when I tested last time. When I returned to distlists
>> today I realized that this problem originated from the fact that some
>> of the users I was trying to add did not have an email-adress.
>
> ah ok...
>
>> So I actually implemented part of what you suggest below (the optional
>> "uid" attribute) since it is required for Turba to work
>> correctly. Otherwise I get the message "4 users added successfully"
>> and wonder where they actually are in my contact list :)
>
> ok... i had also already observed this behaviour...
>
> @bernhard: a kolab distlist is for sending mail, but as a groupware,
> kolab should be able to manage contact details beyond email usage
> scenarios. imagine the following situation: you use your kolab client
> as an address management tool. you take part in some sort of event and
> want to create an address list with all participants in the event, but
> you do not have everyone's email address. albeit, you want to create
> the complete distlist, print it out, take it to the next event meeting
> and ask for address list completion.
>
>> This highlights a conceptional problem though: As Bernhard mentioned
>> in his other mail the Kolab concept of a distribution list is a list
>> you can send mail to. Turba currently only has the concept of a
>> general group of contacts. This is of course useful, too, but it is
>> without a question a different concept.
>
> indeed!!!
>
>> So if you edit distribution lists in other clients at the moment you
>> might experience some incompatibilities.
>>
>
> ok...
>
> [from here on i will reorder your quotations]
>
>> Question is if you will be able to get enough overlap between the
>> concepts of the different clients. Turba sees the list as a group of
>> existing contacts. This is something different than a list of emails.
>
> we certainly do not want to implement two different kinds of lists in
> kolab/horde.
Why not?
I admit I didn't check possible implementation details in Turba yet
but with the turba/lib/Objects.php interface there might be
possibilities like that.
> the question is, if we can bring kolab's list style and
> horde's group style closer together.
>
> this means we have to find a way to keep smtp-address/display-name in
> a horde group (distlist implementation in horde). let me propose an
> approach:
>
> kolab-abook: userA userB distlistA (userA userB userC)
> ->
> horde-abook: userA userB userC[hidden in horde] distlistA (userA
> userB userC)
>
> when loading the kolab-abook into horde/kolab-cache, the kolab driver
> has to auto-generate a virtual userC as a horde-contact on-the-fly. if
> possible, this userC should be invisible in the horde view of the
> abook and it should not be added to the kolab-abook either.
Sounds complex and hard to implement but maybe I'm wrong. I would need
to dive into the code.
>
> if something like this could be implemented into horde's kolab driver,
> then we could use smtp-address/display-name entries in a distlist /
> horde group without having a (visible) contact (turba object) for this
> person.
>
> of course, we cannot change horde WebGUI too much, in horde we cannot
> add contacts to a distlist / horde group without explicitly adding
> them to the abook as individual contacts. but this is acceptable to my
> point of view.
>
> more important is that horde can display kolab distlists that have
> been created with other clients.
Yes, this is the primary point. What would be good to know is how the
different clients see distribution lists. How does Outlook handle the
lists? What does Kontact do? Do they all view distribution lists as a
simple list of e-mail addresses without a connection to a contact
object in the same folder?
If they do and this is the desired function of a distribution list,
then I believe there needs to be another type of list object within
turba. I don't think bridging the turba group and the distribution
list concepts is the best option but as mentioned above I might be
wrong and I'm definitely open to patches.
> the kolab-format for distlists is not
> object oriented (distlists can contain smtp-addresses not found in the
> same abook), thus horde as a kolab client should know a way of dealing
> with that.
Indeed.
>
>>> o kolab format proposal for cascaded distlists and uniquely identifiable
>>> members:
>>>
>>> <!-- Distribution-list specific fields -->
>>> <display-name>(string)</display-name>
>>> {<member>
>>> <display-name>(string)</display-name>
>>> <smtp-address>(string)</smtp-address>
>>> <uid>{string, optional}</uid>
>>> </member>}
>>> {<distribution-list>
>>> <display-name>(string)</display-name>
>>> <uid>(string, not optional)</uid>
>>> </distribution-list>}
>>>
>>> with the kolab format change, we could discuss further issues like:
>>>
>>> o add people to privdistlists, that do not have an email address (yet)
>>
>> Implemented, albeit with the possible cross-client difficulties
>> mentioned above.
>
> GREAT!!! but is an implementation sensible while the format change
> proposal has not even been officially proposed on the kolab format
> list?
The change is fully within the format specs. Client specific
attributes are no problem and need to be preserved by the other
clients. And it usually helps if other people have access to the code
and can test it for problems in real world situations.
Of course discussing this is also good and needed but this happening
right now :)
>
> we probably need a proposal on the kolab-format list, did you already
> cross-post this? (i guess i have to subscribe to one more mailing
> list...)
First I'd like to clarify if all current Kolab clients see a
distribution list as a simple list of e-mails. If that is the case
then we don't need to discuss adding an optional "uid" attribute but
rather create a new "group" object that solely uses "uid" and groups a
set of existing contacts in a folder.
The distribution list support would then need a different
implementation.
>
> ok, so let's suppose the other kolab people like this optional add-on
> uid tag... (i do like it).
>
>> The Kolab UID does not allow cross referencing between IMAP
>> folders. For a globally unique UID that could be used for referencing
>> you'd need something like
>> 123456 at user/wrobel/Contacts at kolab.example.org which we don't have and
>> which would turn out to be a really complex topic.
>
> ok, so i suggest dropping this. from the kolab-point-of-view a uid tag
> shall only be there, if a contact with the same
> smtp-address/display-name is stored as a contact in the same abook
> (IMAP folder).
>
>>> o move distlistA from abookA to abookB (including users from
>>> both abooks?)
>
> kolab point-of-view: moving a distlist from abookA to abookB, should
> remove all the uid tags from the distlist (at first). then abookB must
> be searched for contacts that match items in the distlist by
> smtp-address (primary?) and display-name (or (primary) smtp-adress
> only?). the uids of these contacts in abookB must then be added to the
> distlist members.
>
> horde point-of-view: when the distlist is moved to abookB, abookB must
> be searched for matching contacts (contacts in distlist and abookB).
> all missing contact objects must be auto-generated in abookB (hidden,
> virtual, see above).
>
>>> o how about if userA is in distlistA and userA is deleted???
>
> kolab: this should remove userA's uid tag from the distlist (but the
> smtp-address / display-name should be kept).
>
> horde: the turba object must be deleted and a similar virtual turba
> object has to be created (hidden), but not stored to the kolab server.
>
>>> o the uid in the member tag and the distribution-list tag would
>>> make cross
>>> abook references much easier to handle as well, same with people having
>>> multiple emailaddresses
>>>
>
> for kolab distlists that do not (yet) contain uid tags for the member
> entries, the uids will be added the next time the distlist is touched
> (modified). the clients should be able to handle distlist without uid
> tags. and kolab should also be able to store non-email contacts in
> distlists (groups).
Reading through your descriptions here enforces the impression I had
above: distribution lists as a list of e-mail addresses and a group of
uids are fundamentally different things. And I think both do not mix
very well together.
We should really clarify first how the other clients model this at the
moment. Are the entries in distribution lists linked to real contacts
in the same folder or not?
Cheers,
Gunnar
>
>> Cheers,
>>
>> Gunnar
>
> great progress!!!
> mike
>
> --
>
> das netzwerkteam
> mike gabriel, hamburger chaussee 240, 24113 kiel
>
> fon: +49 431 64 74 196
> voip/voicemail: +49 431 643 643 6
> fax: +49 431 64 74 276
> mail: m.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de
> freeBusy:
> https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
--
______ http://kdab.com _______________ http://kolab-konsortium.com _
p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium
____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de Dr. Gunnar Wrobel
Tel. : +49 700 6245 0000 Bundesstrasse 29
Fax : +49 721 1513 52322 D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Mail at ease - Rent a kolab groupware server at p at rdus <<
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
More information about the devel
mailing list