From dev-return-12477-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Fri Jul 30 21:17:33 2004 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 69830 invoked from network); 30 Jul 2004 21:17:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 30 Jul 2004 21:17:32 -0000 Received: (qmail 82487 invoked by uid 500); 30 Jul 2004 21:17:31 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 82415 invoked by uid 500); 30 Jul 2004 21:17:30 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 82402 invoked by uid 99); 30 Jul 2004 21:17:30 -0000 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Check-By: apache.org Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Fri, 30 Jul 2004 15:17:19 -0600 From: "Brad Nicholes" To: Cc: , Subject: Re: apr-util/ldap/ - sink or really swim to 1.0 release? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N The LDAP error codes probably shouldn't be mapped to the APR error namespace. Maybe the const char **reason should be changed to apr_ldap_err_t *reason instead. This structure could hold the native LDAP error code as well as any other information. The actual return code from the function could then be APR_SUCCESS, any other APR_ error if appropriate or APR_EGENERAL meaning "check the apr_ldap_err_t structure for more information". Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com >>> Graham Leggett Friday, July 30, 2004 12:11:57 PM >>> Brad Nicholes wrote: > I wish I was going to be at LinuxWorld but I guess that means that I > have a little more time to review. Looking forward to seeing the code. > Also if anybody else has time to review the current util_ldap backport > proposals, I would like to get that done and into 2.0, otherwise the > modules remain broken in 2.0 (AFAIK the stuff works great in 2.1). We > might get a little more help on the rest of the LDAP code if what > already exists really worked. A question: The LDAP SDK returns error codes. How should provision be made for them? Should we be mapping them to APR_ namespace protected codes? If so, how? It seems errorno handling is done in apr, not apr-util - but apr doesn't have any knowledge of LDAP. Where should this be handled? Regards, Graham --