[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: I-D ACTION:draft-ietf-ldapext-ldap-java-api-10.txt



> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the LDAP Extension Working Group 
> of the IETF.
> 
> 	Title		: The Java LDAP Application Program Interface
> 	Author(s)	: R. Weltman, C. Tomlinson, 
>                           J. Sermersheim,  M. Smith,  T. Howes
> 	Filename	: draft-ietf-ldapext-ldap-java-api-10.txt
> 	Pages		: 106
> 	Date		: 08-Mar-00

I have reviewed this draft and overall am very pleased with what I see. This
looks like a clean, easy-to-use API and the partitioning of functionality
seems
reasonable to me.

A couple of comments, if I may:

1.  I think LDAPAttributeSchema should expose all of the parameters with a
    get/set API. Right now only some of them are exposed. The reasons for
this
    needed feature are twofold:

    * A programmer might wish to parse the raw string input into its
separate
      fields by simply constructing an LDAPAttributeSchema object and then
      retrieving the separate parameters from the object.

    * The clone() method is made more useful if one can create a "nearly
      identical" object by modifying a clone of the original.

    This comment might apply to other classes which are mostly data
containers
    as well.

2.  Many of the classes should probably implement Serializable to facilitate
    use in RMI and other distributed environments, or for storage in
databases
    as BLOBS. This wouldn't make much sense for the connection class, but
    would be useful for the metadata and data entities and for the
exceptions.

3.  I was very pleased to see such a clear discussion of the ramifications
    of a clone() operation in section 4.6.2. That's very useful information
    and serves to "tighten" the behavior of API implementations.

4.  In 4.6.10, may I suggest renaming the method to getServerPort() so that
    it is clear that the port number from the client is NOT being retrieved?
    Or is this an issue with regard to matching a C/C++ API?

Other than these small points, I think this document represents a very fine
and
readable piece of work, and I commend the authors.

Scott

Opinions herein are my own and do not necessarily represent those of The
Timken
Company or its management.

----------------------------------------------------------------------------
----
Graphical interfaces are great -- you can run dozens of command lines in
them!

Scott D. Courtney, Senior Technical Analyst; The Timken Company, Canton OH
(USA)
Email: courtney@timken.com
Intranet Web: http://www.cis.corp.inside.tkr/~courtney/
Public Web:   http://www.timken.com/
Personal Web: http://www.4th.com/