[Date Prev][Date Next]
Re: AW: ldapsearch return strings
Thank you for that detailed answer !
The clue with the R/O replica is maybe a choise.
In my case I have a bunch of 8 OpenLDAP v2 Servers ( 1 Master 7 Replicas )
and ollowing Produtcs accesses these servers:
.) Sun SIMS 3.x
.) CS&T Calender Server
.) Netscape Communicator Addressbook
In order to have a homogeneous environment/schema files I have 2 choices now:
1.) Switch to Netscape's LDAPv3 Dir. Server
2.) Modify the Source
-> Can you point me to the right direction in the Source Code?
On Wed, 9 May 2001, Kurt D. Zeilenga wrote:
> At 12:31 PM 5/9/01, Martin Hofbauer wrote:
> >Question to the OpenLDAP developers: Why have you decided to do it different to Netscape and Sun's products (RFC ? ,... ) ?
> I think the more appropriate question would be why would you
> expect an implementation to identify a standard track attribute
> type by any other than its standard track name.
> I note that I did not purposely implement the feature
> differently than any particular vendor, I choose to implement
> the protocol as described in the LDAPv3 technical specification.
> In regards to this particular feature, I choose not return
> standard track attribute type by non-standard track names
> as I felt (and continue to feel) that this is most consistent
> with the specification and "be liberal in what you accept,
> but be strict in what you produce" principle.
> I would suspect you'll find implementations that do not
> recognize standard track attributes by any other than their
> standard track names.
> I note that if you want to provide one set of names to one
> family of clients and another set of names to another family
> of clients, create a read-only replica and than alter that
> replica's schema so that the names returned to its clients
> will be returned as you desire.
Martin Hofbauer IT-Consulting
phone : +43 (1) 60 126-34 Bacher Systems EDV GmbH
fax : +43 (1) 60 126-4 Wienerbergstr. 11B
e-mail: email@example.com A-1101 Vienna, Austria