RE: c-api comments

[Anoop Anantha <anoopa@MICROSOFT.com>]

The LDAPControl structure was exposed so that programmers could directly
fill in the OID, criticality etc. One could argue that you could have a
separate helper API - say ldap_set_control() which sets the fields of the
control structure. I see a need for such an API if the control structure was
more complicated and implementation dependent. Otherwise, it will simply
lead to a proliferation of helper APIs.

Again, the BER APIs were required to enable programmers to encode/decode raw
BER data. One example would be the control value field which might be
represented by an arbitrary ASN.1 expression. In this case, I don't see how
standardizing the interface prevents you from implementing a very efficient
BER encoder/decoder. Do you have any particular suggestions to improve the
APIs?

Cheers!
Anoop

> -----Original Message-----
> From:	Leif Johansson [SMTP:leifj@matematik.su.se]
> Sent:	Friday, October 23, 1998 5:15 AM
> To:	ietf-ldapext@netscape.com
> Subject:	c-api comments
> 
> 
> Dear all,
> 
> In the midst of authmeth crazyness I have some comments
> on the c-api draft.
> 
> 
> Some important and obviously implementation-dependent data-
> types are correctly hidden from the api, especially the LDAP 
> and LDAPMEssage types and there are those types where a lack
> of  datatype hiding (again imho) is less of a problem; the
> LDAPAPIInfo and the berval (see below for comments on BER)
> for instance.
> 
> However the lack of datatype hiding for LDAPControl, ldapmod
> and the underlying assumption throughout the document that
> the only container of multiple elements of a given type is
> an array of that type seems to be to be unwarranted. What
> is the reason for not using more accessor-functions (which
> in most cases can be replaced with macros at no performance
> penalty)?
> 
> I am not making idle remarks, the ldap implementation I am
> currently working on uses generic containers for arrays and
> hashtables which greatly simplify memory management. Without
> accessor-functions it is virtually impossible to adhere to the
> c-api as it reads today.
> 
> Furthermore: what is the reason for including the BER encoding
> and decoding specifications in section 15? Why standardize
> this at all -- should not the api hide the details of the
> encoding from the programmer anyway? Many studies indicate
> that marshalling is often an important performance bottleneck
> and it seems inapropriate to have a standard limit the ways in
> which an implementor can increase marshalling performance without
> there beeing a very compelling reason for doing so.
> 
> I have been mulling over this for a while and would very much
> like to have some comments on this from the list and especially
> from the authors of the c-api draft.
> 
> 
> 	Best Regards
> 
> 
> Leif Johansson				Phone: +46 8 164541
> 
> Department of Mathematics		Fax  : +46 8 6126717		
> Stockholm University 			email: leifj@matematik.su.se 	
> 
>     <This space is left blank for quotational and disclamatory purposes.>
> 
>