|
Greetings,
With respect to the LDAPUrl object:
It occurred to me that the intent in the draft is to
throw
the exception MalformedURLException for a non LDAP scheme,
when constructing this object from a full URL string,
thus, an LDAPUrl object MUST contain only URLs with scheme ldap://
Some implementations allow such things as ldaps:// for ssl, etc.
It
seems useful to allow the application to get the scheme to allow for
such
extensions to the implementation, or was the intent that a different
object
represent other schemes even though the syntax is identical except
for the scheme name?
This also brings up another question. Since the only kind of URL
allowed
in the LDAPUrl object is a correctly formatted LDAP URL as defined
by RFC2255, then an application doing asynchronous search operations
cannot
receive the complete URL list for or search continuation reference if
the
URL list contains a non LDAP URL. This is because the only way to
get
the list is via the getURLs() method of the
LDAPSearchResultReference.
Perhaps it should return the URLs as a string array, and let the
application
turn them into LDAPUrl objects if desired. Then it would be the same
as
the getReferrals() method of the LDAPResponse object, which does return
the
URL list a string array. (This is backwards to what I said in an
earlier e-mail, but
now I see the need for Strings instead of LDAPUrls)
------------------------
Steve Sonntag Novell, Inc., the leading provider of Net services software >>> "Steve Sonntag" <VTAG@novell.com> 06-Sep-00 5:17:57 PM
>>>
An application doing its own referral handling may need to make
decisions based on the scheme of URLs returned from search
continuation references or referrals.
Shouldn't the LDAPUrl object provide a method to retrieve
the URL scheme, viz. ldap, http, & etc.
-Steve
|