UserPreferences

WritableLdapAddressBookIdeas


1. Writable LDAP Addressbook Ideas

  1. Writable LDAP Addressbook Ideas
    1. Multiple Distinguished Names
    2. Search Base DN Order
    3. Off-line Support
    4. Group-list Support

Having longed for a good writable LDAP addressbook integrated with open-source mail clients, I have here penned a few thoughts based on my experience with [WWW]Evolution, which is one of the few mail clients that actually has it. These can be seen as improvements over the existing implementation in Evolution, and ideas of how to implement it in other clients (namely Mozilla--there's a great need for a cross-platform mail client that supports this kind of thing). I admit, to begin with, that I don't have much experience with proprietary offerings, like Exchange. I'm also not much of a coder, especially with GUI applications, so I'm putting this out in hopes that someone who is will find it useful.

1.1. Multiple Distinguished Names

It's important to be able to write to different distinguished names (DN) and the user should be able to easily choose which DNs to write to when adding a new contact. For example, you will likely have a personal branch of the directory information tree (DIT) for your own contacts, which will not be shared with other users. Then there will likely be maintained site-wide or division-wide lists of contacts, so, for example, an IT department can easily get a list of support numbers for the various pieces of equipment or a sales department can easily share customer information; the latter probably being restricted to just members of sales department. Finally, one will want to be able to search the entire DIT sometimes, including following references to potentially off-site branches of the DIT.

This can already be done with Evolution by creating multiple addressbook sources and changing the base DN. This solution, however, requires the client to bind to the server multiple times--once for every entry--and will also be sub-optimal with off-line syncing, because the client could end up syncing certain branches multiple times.

1.2. Search Base DN Order

With all these DNs to write to or search, the client be intelligent about the searches (or at least, give the user the option to be intelligent). The user should be able to organize the DNs that his client will search under, to avoid tree-wide searches when possible. The user shouldn't be forced to repeat his search manually when a search in a particular scope returns nothing. Instead, it would be better to have a list of base DNs to search, and when the first turns up nothing (or not what the user wants), to have a "Next" button that searches the next DN on the list, or a drop-down box that allows him to select from the list. This list might not only allow him to have different DNs to search, but also different options, such as scope, depth, and whether or not to chase referrals.

1.3. Off-line Support

Off-line support is one of features I miss most in Evolution (these other things are important for use at a business). At the very least, it would be nice if Evolution would realize when it's offline, and not try to query LDAP servers. Syncing of course is also very important; I currently limp along by dragging the few addresses I need when I'm off-line into the local contacts store. This is one feature that Mozilla/Netscape has. I haven't looked carefully at it, however, I suspect it doesn't do off-line sync as intelligently as possible. To accomodate a user in a large organization (or just a large tree), the off-line sync needs to allow the user to select a list of DNs to sync from, and possibly a depth. Neither the user nor his sys admin would really want him trying to sync the entire organization's DIT, given that there could be hundreds or thousands of entries and that the tree might span many sites.

1.4. Group-list Support

Another feature missing from Evolution is the ability to manage group contact lists. This should really be stored as a list of references to other entries, not as a list of addresses. (I'm a little hazy as to how references work in LDAP, because I haven't worked with them.) The reason for this is obvious--people's e-mail addresses change (could also be used to generate a list of postal addresses, such as for a mass-mailing) and changing every list would be tedious and error-prone. I lost a potential customer because there are no open-source clients that I could find that support this. The customer wanted to replace a Groupwise server but one of their requirements was to be easily able to send mass mailings (they are a school athletic association and they frequently send mass-mailings of things to different sets of faculty and staff of local schools, so it was a legitimate use). The groups they sent messages to were not strict unions of sets and some groups would come and go quickly, so managing it all with a mailing list manager like Mailman would be too cumbersome. I was shown their Groupwise client and how they could very easily create a group and select people from their list to add to the group, and was told when they changed the address in the directory, it was updated for all the lists, so I'm assuming references were in use, instead of lists of addresses.