From: Graham B. <gb...@po...> - 2001-01-31 20:47:13
|
On Wed, Jan 31, 2001 at 05:43:52PM -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. This all sounds good. If it can truly be made optional, or just done via additional methods to the existing ones, then we should add it to CVS > 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 think it is certainly worth considering, can you post the code somewhere so others can see it and discuss it. If its not too big post it to the list, otherwise send me a tar file and I will place it on the sourceforge FTP server > I've got bogged down in the syntax handlers, incidentally. They're > seriously boring to write and there are a lot of them. I can only imagine. Graham. |