[Kolab-devel] Where do we start?

[Stephan Buys]

On Thursday 15 May 2003 04:59, Martin Konold wrote:
> Am Mittwoch, 14. Mai 2003 20:30 schrieb Stephan Buys:
>
> Hi Stephan,
>
> > 1) The ability to easily build the SRC RPMS of the Kolab server from CVS
> > - This might already exists
>
> We are using Makefiles for this currently. Please have a look at the cvs
> (it is available via anonymous cvs since a while)
>

Oops. Will have a look and let you know my success/failures. The ones not in
CVS are the OpenPKG ones correct?

> > - Some script like assemblekolab.sh could be used to quickly take changes
> > from CVS to a state where we can merge changes into Kolab and test them.
> > - Any comments on this?
>
> Where is the difference to the former?
>

Still the same idea (shouldn't have used bullets)

> > 2) There is a patch available that takes "client_ldap_cache" out of
> > Postfix and thus allows us to compile Postfix with LDAP support for the
> > latest OpenLDAP version. This will scale better and need less processing
> > than the what the kolab script does at the moment. (As this will be in
> > "Kolab development" it should be ok to test this?)
>
> Why do you think that this improves scalability? Please explain.
>

Ok - for one thing when we have thousands of users on a server there will
be limitations to the text file. With LDAP we can add indexing on certain 
attributes and the interface is also nice and clean. We also cut out the
processing needed by the kolab script having to collect all the addresses
and rewrite the virtual aliases file.

To me having Postfix use LDAP as much as possible just feels "cleaner"
as LDAP plays such a central role in Kolab.

Another reason I can think of is that the users will be able to use LDAP to
view the alias lists (it can easily be integrated into the web frontend as well)

> > 3) What about splitting the Kolab schema files out to different files
> > again? I would like to add support for 2739 (LDAP Free/Busy URI's) to the
> > server so that the client-side guys can start playing with it. (This of
> > course does not affect the kolab.schema file, I just think it is easier
> > to manage the different Schema files seperately)
>
> I know about RFC 2739 but what do you expect to gain from putting the
> Free/Busy information into LDAP?
>

Not the Free/Busy information but a URI to the Free/Busy information.
I can think of several advantages for future client development. It will be
easy to find Free/Busy information accross different organizations and
when using several aliases. (ie Free/Busy is not as hap-hazard as using
the %NAME% portion of an email address). 

This obviously does not affect Clients like Outlook but can set the 
benchmark for future KMail as well as other clients. You will not be
restricted to a single Free/Busy repository but will be able to use several
in different organizations.

IMHO it just "feels right?"


> > 4) We also need to think about a solution around distribution list.
> > Either through aliasing with postfix or through integrating a mailing
> > list manager.
>
> As written in another email I prefer a mailing list manager plus client
> side lists. In addition we have bulletins via public folders.
>

Should we not choose one good solution and integrate it into Kolab? (As
with the other components? Postfix vs. Sendmail for instance).
This way we can integrate it into our Kolab admin frontend? 

The way I would like to see it is that Distribution Lists should show up in
LDAP (and subsequently in Outlook through the Bynari LDAP connector for 
people to use it effectively.)


> Regards,
> -- martin
>
> Dipl.-Phys. Martin Konold
>
> e r f r a k o n
> Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
> Nobelstrasse 15, 70569 Stuttgart, Germany
> fon: 0711 67400963, fax: 0711 67400959
> email: martin.konold at erfrakon.de
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at intevation.org
> https://kroupware.org/mailman/listinfo/kolab-devel

-- 
Stephan  Buys
Technical Director
Code Fusion cc.
Tel: +27 11 391 1412
Mobile: +27 83 294 1876
Email: s.buys at codefusion.co.za