directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: Reading Binary Attributes
Date Fri, 06 May 2011 21:29:26 GMT
On Fri, May 6, 2011 at 5:34 PM, Stefan Seelmann <> wrote:

> On Fri, May 6, 2011 at 3:30 PM, Daniel Fisher <> 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.

+1 Absolutely 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.
Yes a nice optimization if available.

> 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



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message