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.


Reply via email to