On 6 mai 2011, at 16:34, Stefan Seelmann wrote:

> On Fri, May 6, 2011 at 3:30 PM, Daniel Fisher <[email protected]> wrote:
>>>> Specifying BinaryAttributeDetectors might also be interesting in the case 
>>>> where the server does not advertise the location of the its schema in the 
>>>> RootDSE. But it would leave the connection being halfway schema aware, 
>>>> which might be complicated to handle at first sight.
>>>> Something we can discuss about though.
>>>> 
>>> yeah, the problem here is to link such a mechanism into the schema
>>> manager, but honestly I don't think it is a good
>>> idea to let user define some behavior to handle the attribute type
>>> apart from what is already defined in the schema through syntax.
>>> 
>>> OTOH this conversation makes me think that we should also make
>>> connection schema aware by default, instead of the current choice
>>> of letting users call loadSchema() to make it schema aware.
>> 
>> I think you want to support both behaviors. The vast majority of LDAP
>> clients do not need to be schema aware. They just need to read strings
>> (and sometimes bytes) from the server. Forcing a client to synchronize
>> schema updates with their server would place an undue burden on
>> application deployers that depend on LDAP.
> 
> I agree with Daniel. LDAP is often used to authenticat users, so only
> a connect and bind is required. In that case loading the schema would
> be too expensive.
> 
> Another thing: the schema may be big, say up to an Megabyte. So you
> don't want to load the schema on each connect/bind. In Studio we cache
> the schema based on the createTimestamp/modifyTimestamp of the
> subschemaSubentry entry, but that's quite tricky and doesn't always
> work.
> 
> Loading the schema is also dependent from the access control rules.
> Some servers don't allow reading the schema for non-admin users. So in
> that case the connection can't be made schema-aware.
> 
> And using the built-in schema doesn't make sense at all, IMHO. If we
> don't know what the other server is it doesn't make sense to assume
> the schema would match.
> 
>> If you don't like exposing the BinaryAttributeDetector, you could
>> simply store the raw byte[] in the Attribute along with the UTF-8
>> encoded string for every attribute. If I remember correctly this is
>> what JLDAP does. Clients would then have the flexibility to use either
>> data type regardless of the schema.
> 
> That's a great idea, +1

I agree with Stefan and Daniel on both points.

Regards,
Pierre-Arnaud

Reply via email to