A few things needs to be fixed, asap: 1. Documentation. 2. Line "truncation" to 80 characters. 3. Base64 encoding of binary data. 4. File handle management, passing files etc. 5. Clean up code.

Veselin Terzic wrote: > Leif Hedstrom wrote: > > > > Yeah, I've tested it. There's a typo above though, it should probably have > > been > > > > $ldif = new Mozilla::LDAP::LDIF(*LFD); > > oops, now i know :( Yeah, sorry about that, my fault. I'm looking into improving this module, *and* include some documentation and examples. :). > one thing that might be useful. Entry.pm should have something that > scrolls over all attributes in an entry, like $entry->nextAttribute(), > that will return attribute name-value array. Hmmm, I might try to implement so that each() works as you'd expect (i.e. only return attribute names). Let me look into it, I can see where this is useful. > 1. "dn" is not treated as an attribute so i cannot $conn->search if > my filter is entire "dn:" ?! You don't have to. Do the search with a scope of "BASE", and the search base with your DN, e.g. $DN = "uid=leif, ou=People, dc=netscape, dc=com"; $SCOPE = "BASE"; $FILTER = "(objectclass=*)"; $entry = $conn->search($DN, $SCOPE, $FILTER); This will return exactly one entry, if it exists. If it doesn't exist, there's nothing returned (of course). This is the common way of "browsing" an LDAP directory, but for some reason it's one of the most common questions I get. I might add some method (like getEntry()), like $entry = $conn->getEntry($DN); Let me look into that... > 2. Once I obtain appropriate LDAP entry in my $entry2, I cannot scan > through attributes in the $entry1 (obtained from LDIF, unknown list of > attributes, must be "dn" plus N attributes) and perform appropriate > $entry2->setValue OR $entry2->addValue before doing > $conn->update($entry2); > > what do you suggest here? Does the above help? On my ToDo list, I have a new method called "synchronize()". With it (it doesn't exist yet), you'd just have to do: $entry->synchronize($entry2); which would then do the appropriate modifications to $entry to match $entry2. There might be a few flags (to tell it to not delete attributes for instance), and probably an optional list of attributes (to tell it to only synchronize some attributes). This method most certainly won't make it for PerLDAP v1.1, but as soon as we've released v1.1, I'll start working on v1.5, which will be developed on a separate branch on the Mozilla CVS server. We encourage people to participate in this development, so when we start that, I'm going to post a list of things we need to work on, and solicit for help. -- Leif

Hello, I've built Netscape C-SDK-3.0 and after that PerLDAP-1.0. Looks good, but I've found a few problems: 1. LDIF OO methods don't seem to work or I am missing something I call open (LFD, $ldif_file); $myentry=&readOneEntry(LFD); $myentry->printLDIF(); and there is nothing ?? what's wrong here. 2. When I want to perform an LDAP operation on an LDAP server (add,delete,modify) that is a consumer (i.e. gets it's data from another server by way of replication) my perl program core dumps if this server is more than 3 levels deep. For example ds1 -> ds2 -> ds3 ->ds4, where sign "->" means "supply". I use "rebind" procedure to follow referrals back to the top where master server s1 sits. I can successfully work with s1,s2,s3, but not with s4 or deeper. Is this limit in SDK or in PerLDAP? 3. Where can I get latest (BETA) PerLDAP stuff? I've heard some problems have been fixed. Thanks -- Veselin Terzic Phone: 650-425-5215 DHL Systems Inc. Fax: 650-425-5019 700 Airport Blvd., Suite 300 Email: vterzic@systems.dhl.com Burlingame, CA 94010 #include <std/disclaimers.h>

Setting all current Open/Normal to M4.

Clearing "M" field since Directory product is not used for 5.0 specific project bug metrics and will mess up our queries on milestones.

John Kristian has donated a new version of LDIF.pm, which we'll add for PerLDAP v1.3/v1.4. It's available in his work area: file:/u/kristian/PerLDIF/mozilla/directory/perldap/

Closing this bug, since John has checked in his new LDIF.pm module...