[Kroupware] public folders (was: Re: Kroupware replacing Exchange)

[Bo Thorsen]

On Wednesday 05 February 2003 12:17, Tassilo Erlewein wrote:
> On Wednesday 05 February 2003 11:10, Bo Thorsen wrote:
> > Yes and no. We have the LDAP contacts working fine, so that's a
> > replacement for the shared folder (note: the LDAP IO slave in KDE 3.1
> > is readonly, so uploading a new contact can only be done with the web
> > interface. I agree this is a problem. In KDE cvs, the slave is
> > read/write so you can save contacts directly to the LDAP server).
> > Actually it's IMHO even a better way to have contacts on LDAP than in
> > a shared folder, because you can get to them from other LDAP enabled
> > applications too.
>
> That's a point that has been quite often discussed.
> We use to differentiate two things (actually three ;-)):
>
> 1. "Address Book"
> 2. "Contacts"
> 3. a mixture of the above
>     a "collection of business cards" for a certain user group,
> frequently accessed and modified
>     we can do that with a shared/public folder consisting of above
> mentioned emails. No difference, only that it's not a subfolder of your
> INBOX. Where you attach it to your folder view is up to you.
>     Unfortunately you will have to wait a bit for the KDE client to
>     support IMAP shared folders.
>
> LDAP IMHO is a good thing if you seldom change something, you need very
> often read and authentication access. LDAP is IMHO not suited to run a
> company-wide contact database, which is frequently changed by lots of
> users. Think of a phone book. You don't change it yourself but fill in
> a sheet and let the telephone company (administrators, maintainers)
> change it.
>
> We slightly modified this approach because of a customer demand.
> In Kolab, a user can update his own LDAP entry in the global address
> book.
>
> I hope this clearifies everything a little bit.

I agree with the above. The only point I was making was that with the=20
addressbook in KDE 3.2 have all the contact capabilities and is able to=20
upload these to an LDAP server or to a shared folder. I expect that=20
uploading contacts to a company wide LDAP server will definately not be a=20
good thing, but if we're able to make "subdirectories" in the LDAP dir on=20
the server, then the shared folders for contacts can also be implemented=20
as making a subdirectory on the LDAP server and giving access rights to=20
the group of people involved with the contact. This isn't a change in=20
current behaviour, just another possibility.

Bo.

=2D-=20

     Bo Thorsen                 |   Praestevejen 4
     Senior Software Engineer   |   5290 Marslev
     Klar=E4lvdalens Datakonsult  |   Denmark