[Kolab-devel] distributionlists testing

[Bernhard Reiter]

Hi Mike,

On Monday 21 April 2008 14:21, Mike Gabriel wrote:
> i would  
> like to discuss a feature list around private distribution lists and  
> see what is desired, what can be applicable, etc.

(just to be double sure: we are talking about the distributions saved
in a contacts folder which can be edited by those who have access.)

>    o do we want to allow cross address book references in privdistlists?
> (userA in abookA and userB in abookB can both be added to distlistB in
> abookB or distlistA in abookA

IMO: No. There is power it cascading distribution lists, but also pitfalls
for the user interface and implementation. We could implement loops then
and could not predict sane dereference of all email addresses.

>    o move distlistA from abookA to abookB (including users from both
> abooks?) 

One design idea of Kolab is that a primary email is a very good way
of uniquely identify persons. As this is world-wide unique and should not
be given to someone else ever.

So you could take users from abookA and abookB to be put in a distribution 
list object. Of course, this is only useful if allreader of the folder you 
put this distribution list in, have access to the user objects.

> o how about if userA is in distlistA and userA is deleted??? 

At least a warning would be appropriate I guess.

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

Proposals like this should go to kolab-formats. Best is to include a rational
with use cases and considered alternatives.

> we could discuss further issues like: 
>
>    o add people to privdistlists, that do not have an email address (yet)

My use case is to send emails to the distribution lists, thus all member 
should have an email address, otherwise this conception breaks.

>    o remove contacts from an address book, but keep the contact in the
>      distribution list (i know, this will be difficult with horde/turba's
>      internal abook structure, but other clients like outlook support this)
>    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
>
> TYK: my basic intent is the following: where i am employed, people  
> work with another groupware using outlook clients. i would actually  
> like to avoid the next product upgrade of our groupware, but it is  
> actually really due. i would be much happier to setup kolab at work,  
> but the great hurdle is the - until now - rather weak private  
> distribution list support in kolab clients.

What are the missing use cases in particular?

> for setting up kolab we will need a webmailer, that supports  
> privdistlist feature and the privdistlist handling of the webmailer  
> should be fully compatible to what people can do with outlook/toltec.  
> outlook supports two different kinds of entries in private dist lists:  
> object references vs. name+mailaddress entry.
>
> in terms of privdistlists i favourize kolab to catch up with what  
> (unfortunately) the majority of groupware (outlook) users is used to...

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20080423/31e95960/attachment.sig>