|
Rob,
That sounds correct. I appreciate the clarification.
-Steve
>>> Rob Weltman <robw@worldspot.com> 11-Oct-00 12:35:16 PM >>> Steven Sonntag wrote: > Rob Weltman wrote: > > > All the per-instance options can be eliminated immediately in favor of setConstraints/setSearchConstraints. And with nothing left (except possibly STRING_FORMAT), I agree that we can afford to add the two suggested additional methods to get the bound protocol level and the properties Hashtable used on binding. > > > > Rob > > I'm just curious why STRING_FORMAT is possily global. If I understand this API correctly > an application could choose to get all data in T.61 format whether or not the connection is V2 or V3. > > Is it global because an application will probably deal only with one character set, or because of of something > intrinsic to the connection itself. > > -Steve It doesn't need to be global to the connection, but the purpose of the API was to accomodate the wide range of character set encoding behavior of current LDAP servers. While the correct behavior is to return T.61 to an LDAPv2 client and UTF8 to an LDAPv3 client, some servers always return UTF8 (or do no conversion at all, just returning whatever was stored - which might be T.61 or UTF8). For this purpose, it makes sense to set the format once after a connection has been established (and the client knows what type of server it's talking to) for all threads or objects sharing the same physical connection. Rob |