Re: dump method for binary values

[Kurt D. Z. <Ku...@Op...>]

I'd suggest that the dump method produce LDIF and make use of the
base64 form as appropriate (non-printable characters, leading/trailing
spaces, etc.).  Producing LDIF requires no knowledge of schema.

Kurt

At 05:43 PM 1/31/01 +0000, 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