|
Kurt,
In reviewing my previous statement, I realize I spoke
hastily.
There are actually three cases here, and the current
draft is adequate with respect to
referrals/continuation
references when automatically following referrals.
1) if automatically following referrals, the
application does not
need to know whether the URL list is from a referral or a search
continuation reference. When following the referral, the API
handles, under the covers, the setting of the appropriate scope
and reissues the modified command on the new connection.
2) When not automatically following referrals on a synchronous
request, if the application gets an LDAPReferralException as the
only result, the LDAPReferralException is a referral. If the
application receives other results, then the LDAPReferralException
is a search reference. In any case whether it is a referral or
continuation
reference has no effect on the referral handlers as they are not used
when not following referrals. To not follow referrals is the
default
behavior.
3) Automatic referral following is not allowed on an
asynchronous
request, and the application knows if the response is a referral
or a search reference by the returned message type.
I hope this clarifies the issue.
-Steve
>>> "Steve Sonntag" <VTAG@novell.com> 16-Mar-01 9:01:52 AM
>>>
You are correct. with respect to referrals/continuation
references.
The API should inform the user whether the URL
array is for following a referral or a search continuation. Probably
a
boolean argument is adequate to convey this information.
-Steve
>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 15-Mar-01 5:10:26 PM >>> > The API doesn't distinguish between LDAP search continuation > references and LDAP referrals, presenting a unified interface to the > client for handling the two. I would think that an referral/continuation handler provided the application would need to distinguish the between a search continuation and a referral. I note that chasing requirements for referrals and continuations differ, for example how the client needs to process an LDAP URL with an absent base differs. Also, I note it would be useful if methods of LDAPUrl (4.41.1) distinguished between an explicit and default parameters of an LDAP URL. For example getScope() could return SCOPE_DEFAULT if an explicit scope wasn't provided. As this behavior is likely only useful to applications doing their own referral/reference chasing, likely best to have some means to enable/disable this behavior. What does "explicit URL string" imply? Does it imply that URLs with implicit parameters are not allowed? e.g. LDAPUrl("ldap://") What does "full-blown LDAP URL" imply? And "nearest X.500/LDAP"? nearest? X.500? Also, I suggest the default port be 389 so that: LDAPUrl("ldap://localhost") and LDAPUrl("localhost", null, null); are equivalent. Kurt |