[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Multiple extended responses per request
Hi Dave!
You'll want to do something similar to the multi-stage bind. The LDAP
client will have to send a new operation request to get each successive
response from the server. So, you'll have a flow like:
CLIENT SERVER
Extended Request (initial)
------------------------------------------>
Extended Response (initial, not done)
<------------------------------------------
Extended Request (get more please)
------------------------------------------>
Extended Response (next, not done)
<------------------------------------------
Extended Request (get more please)
------------------------------------------>
Extended Response (next, not done)
<------------------------------------------
...
Extended Request (get more please)
------------------------------------------>
Extended Response (final, done)
<------------------------------------------
Bruce
At 03:50 PM 9/8/99 -0600, you wrote:
>While developing an LDAP v3 extension, a developer here wanted to be able
to send multiple responses against one request. This was relatively easy
to support in our server code, but the published client APIs don't support
more than one response per message id. While RFC 2251 for LDAPResult is
quite clear in stating "to indicate the *final* status of a protocol
operation request", the ExtendedResponse is not quite so definitive: "The
server will respond to this with an LDAPMessge containing the
ExtendedResponse."
>
>Given the precedent of an interim response in the Search verb as well as
Persistent and Triggered search, it seems to make sense that an Extension
might want to do this as well. We were going to use different OIDs to
indicate if a response was interim or final until we ran into the client
issue.
>
>Is this feasible? reasonable?
>
>Looking for feedback.
>
>Dave
>
>
>
>
>
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com