[Kolab-devel] distributionlists testing

[Mike Gabriel]

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. 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.

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. 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.

>>    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?

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...)

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).

> 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