Hello Michael, 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?
> >> what to be worry is did you have the >> right to write that LDAP addressbook :) > > > Let me summarize the issues again: > - DIT issues when adding new entries How about letting you choose before addind it :) > - access control (very complex server-side issue) What problem arise 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. > - 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 :) did you know any LDAP Addressbook in the markets that can work as what you told? >> 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) > >> | 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? Thank You Chan Min Wai Ps. May be we need some chat... :)
