On 2012-01-30 13:45, lists@nrd.fr wrote:
Hi RC-Dev list,
I'm setting up an LDAP shared address book and while googling for information I found this thread in your archives (I wasn't a list member then):
(oct 2011)
(nov 2011)
Please let me add a few comments to this thread. I Hope this is the right place to post and that my English is good enough. Forgive me otherwise.
- UID or Email as RDN?
When working with small companies and/or workgroups it's quite frequent to see several people sharing a single email address, typically something like "little_company@some_big_isp.tld". This is my everyday experience with small companies and small local administrations too (I live in a rural area).
Using mail as the RDN makes it impossible to add more than one contact in such situations, even if you want them because, in spite of a common work mail address, different people still have different mobile numbers, different home mail addresses, etc.
So, IMO it would probably be better to use a dynamically generated UID as RDN.
Between your users' user accounts and contacts added to LDAP, you can choose to use a different LDAP OU, and use a different RDN for each type; Your users could be in LDAP with the 'uid' as the RDN attribute in ou=Users, while your contacts could be in an ou=Contacts using a cn or displayName (or mail) attribute as the RDN.
- RC writing data to the address book
IMO the main advantage with LDAP is having mail clients being able to read a shared address book. Getting RC writing to the directory doesn't look that important to me: suppose you get the feature to work with RC, as an admin you are left with the same problem for each other client you may want/need to support at your company. Until there is some standard address book schema that every client should support, but I don't know of any right now.
So, IMO a much simpler approach is to stick with a dedicated application to setup and manage the address book, and look for good read capabilities of mail clients. I mean that more flexibility in the way RC can do the mapping between LDAP attributes and contact fields is IMO the most important feature to focus on.
One challenge with LDAP is the aspect of "Road Warriors" - people that run clients on their laptops and could connect (to LDAP) from anywhere in the world. If you have such users, you can't protect the information in LDAP through firewalling, and you need to set the access rules so that no anonymous querying is allowed.
Another challenge with LDAP is the maximum size of queries. While, presumably, returning 4000 entries to a single query is still OK (after a little tweaking), the same does not apply to returning tens of thousands of results. I suppose the size and type of an organization is important, as a sales-type organization is much more likely to collect large volumes of contacts than, say, a small carpentry business.
If address book(s), or sharing thereof is one of the challenges you are facing now, perhaps the next big thing on your list is Calendaring?
Unaware of which client and server applications and/or platform your seeking to support in your environment, please allow me to shamelessly plug Kolab Groupware[1]. In the interest of full disclosure - I work for Kolab Systems (see signature).
If needed, I can certainly create you two or more accounts in our demo environment, so you can see for yourself whether it fits your needs - please contact me in private.
Kind regards,
Jeroen van Meeuwen