Re: dump method for binary values

[Jim H. <ha...@us...>]

Thanks for requesting clarification of my language.  To be more precise, I
would like to see Net::LDAP::Entry->dump() (or possible a variant like
asciidump() ) recognize attibute values have any bytes whose values are
outside the range 32-127 base 10.  For such attributes it would display
something like "NOT ASCII" as ldapsearch does or "(NOT PRINTABLE)" or
something similar.  I am not looking for a change in the API, only what is
displayed.

  --Jim Harle

On Wed, 31 Jan 2001, Chris Ridd wrote:

> Jim Harle <ha...@us...> wrote:
> > I would like to see the dump method for entries made smarter about binary
> > values of attributes.  Right now, it just dumps them as regular characters
> > which messes up terminal emulators if the wrong values come across.  the
> > ldapsearch command on Solaris shows a value of NOT ASCII for them, which
> > is much friendlier.
>
> Net::LDAP does not use the schema information in any way at present. This
> is both good (lean and mean and it doesn't mess around with stuff) and bad
> (sometimes confusing behaviour.)
>
> So it currently cannot tell what is a 'binary' attribute. I guess by binary
> attribute you mean 'human-readable', as per the table in section 4.3.2 of
> RFC 2252, and not just those attributes with binary AttributeDescriptions.
> Or do you just mean 'printable using the current display device'?
>
> I have some diffs which are probably broken ATM which changes this. But it
> also changes the existing value API.
>
> IIRC I changed it so that the $ldap object gets a useSchema() method, which
> takes a Net::LDAP::Schema argument. When this is used, the new value API
> gets switched in.
>
> The new value API is roughly this:
>
> Net::LDAP::Entry->get() returns an instance of Net::LDAP::Attribute.
> Net::LDAP::Attribute->type() returns the attribute type (name)
> Net::LDAP::Attribute->values() returns an array of Net::LDAP::Value objects.
> Net::LDAP::Value->string() returns undef for an attribute which is not
> human-readable, or the string if it is
> Net::LDAP::Value->octets() always returns the raw bytes received from the
> server
> Net::LDAP::Value->description() returns the AttributeDescription eg "binary"
>
> It's all fairly logical IMO, but it involves several extra method calls
> when accessing values which could be a bad thing from a performance point
> of view.
>
> There about a million (slight exaggeration, actually 116 :-) subclasses of
> Net::LDAP::Value implementing syntax handlers for all the known syntaxes.
> These syntax handlers can do things like 'explode' their values into
> pieces, which is useful for values of DN syntax for instance. They also
> know about values with "binary" AttributeDescriptions.
>
> Is it worth persevering with these schema changes? It provides you with
> your desired semantics in a clean way, and it doesn't lose the current
> means of accessing the 'raw' data, which I find an attractive feature of
> Net::LDAP. (Though it does this with a different interface, natch.)
>
> I've got bogged down in the syntax handlers, incidentally. They're
> seriously boring to write and there are a lot of them.
>
> Cheers,
>
> Chris
>
>