let me summarize that: If we can't build "the perfect" write enabled LDAP based Addressbooks leave it.
Reason:
There are some large companies which couldn't use this feature due to their LDAP structure restrictions (DIT, Schema,...)
I agree!!
There might be some mid size companies (~ 2000 people) which where able to achieve a single personal address source which is LDAP based and have restrictions making it "Mozilla compliant"
I don't agree!!
that it would affect the majority of Mozilla users who wants to maintain a shared address book.
Large companies (> 50'000 people) have anyhow multiple places (synced or not synced) where they maintain personal information. Belief me, I know that. They have even multiple LDAP servers for similar purposes. One as general address book, one for PKI (Entrust), one for Microsoft client and server authentication (MS Active Directory), one for Web server access control, one for UNIX authentication, ...)
It's a pity we don't live in a perfect world.
Imagine this company would use Lotus Notes as their Corporate Mail tool - they would have to maintain a Lotus Notes Directory service anyhow.
Facit:
Dear mid-size companies we want to excuse for implementing something in Mozilla which is not very useful for you; but all the others be happy you get a easy and simple way to maintain your shared addressbook which is perfectly integrated into Mozilla.
Cheers Roland
PS: Who useful might the Mozilla Chat client be for companies?
Michael Stro"der " wrote:
Chan Min Wai wrote:
Michael Stro"der:
Chan Min Wai wrote:
Who care if there have to be complex DIT, the basedn already told us where to write,
This is a over-simplifying assumption. Not true on many corporate directories.
I'm not sure how corporate do their directories, mind to have some explain or example?
uid=michael,ou=Department 1,ou=People,dc=stroeder,dc=com uid=chan,ou=Department 2,ou=People,dc=stroeder,dc=com ^^^^^^^^^^^^^^^ depends on person entry ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ base DN of address book search
- DIT issues when adding new entries
How about letting you choose before addind it :)
Possible. But this requires a directory browser which in turn is too difficult to be used for most people.
- access control (very complex server-side issue)
What problem arise here?
All kind of open questions regarding the security policy of the directory. I'm not keen on getting into details here.
- multi-valued attributes (there's currently not even good support for reading them)
I don't seem to have any way to solve it either.
Currently it's completely random which e-mail address is used by Mozilla Messenger if you have more than one in the 'mail' attribute...
- schema issues require complex client configuration (mozillaPerson is not the way to go in most corporate directories)
One could imagine that functionality is added which solely allows to modify an existing entry. This would make it possible to use Mozilla for user self-service with a corporate directory and avoid the bigger issues with DIT and schema. Still smarter handling of multi-valued attributes is needed.
I think you need something else and an LDAP addressbook :)
I did not request the implementation of LDAP write access in Mozilla. I don't need it and I don't see much sense in implementing it. It's not worth the effort.
I'd like to have the ldap_2.customDisplayUrl feature of NS Comm. 4.5 which enables me to point the user to a directory-specific web application which is implemented for a specific directory. (I used my local LDAP address book with my web2ldap this way.)
did you know any LDAP Addressbook in the markets that can work as what you told?
The question is whether you need it at all. IMHO corporate LDAP address books are maintained in a different fashion. And for adding/modifying personal address book entries you can simply use the local PAB.
Make one AB for read and one AB for write.
???
This is somehow tht way I think to solve the DIT, make one the address book(s) with the following dn :( dn:ou=sales,dc=ex1,dc=net and one other with dn:ou=enginnner,dc=ex1,dc=net may be this will solve a few small issue (This is just a suggestion, not a solution)
Note that the DIT issue arises because part of the DN could be derived from attributes of the entry you would like to add.
| Write/Update each attribute individually so you only get an error | message for those fields you can't update/add.
Agree.
This sacrifies the atomicity of the LDAP write operation.
I'm not too sure about this how about some explain?
With LDAP an AddRequest or ModifyRequest either succeeds or fails. The action is guaranteed to be atomic. If you split addition or modification actions into several actions you will loose that property.
Ciao, Michael.
