Re: [provision] RequestType should require requestID.

[Jeff Larson <Jeffrey.Larson@Sun.COM>]

Gary P Cole wrote:
> Well, I may be explaining this poorly, but the PSTC's resolution in the 
> most recent Face-to-Face was that any requestID from the original 
> request should also identify the asynchronously-executing operation. - 
> if the original request specifies requestID, then the response must 
> specify that same requestID.
> - if the original request omits requestID, then the response must 
> specify a requestID that the provider generates.
> Either way, a requestor should specify the requestID from the original 
> response as the value of the 'asyncRequestID' argument in a 
> statusRequest (or a cancelRequest).

Yes, I thought that was how we specified it in 1.0.

> 1) If the requestor specifies a requestID in the request, then the 
> requestor KNOWS the requestID value to supply to the status or cancel 
> operation (even if the requestor does not receive the response).

Sure, but my point is that the requestor will always receive a response.
If it doesn't then something very bad is happening that probably
renders the dialog invalid anyway.

> 2) If the requestor specifies a requestID in the request, then we don't 
> have to restrict the requestor to one request at a time.  Theoretically, 
> one could send a bunch of requests, receive a bunch of responses, and 
> match them up using requestID.  A provider should be able to achieve 
> better throughput by queuing requests (and dispatching multiple 
> threads).  A requestor might be able to achieve better throughput if the 
> protocol weren't quite so synchronous.

We don't restrict them now.  If they want to send a bunch of async
requests, they use request ids and poll.  If they want to send a bunch
of sync requests, they launch a bunch of threads and block.

The concern seems to be that it's a burden for the provider
to send back a bunch of little "async request launched, here's your id"
responses.  I'm not convinced it is.  But if it were, then the requester
is free to specify their own request id, close the socket and move on.

> 3) What's bad about requiring a requestID?  How big of a burden is this?

It's not a big burden, but it's an irritant if it doesn't really serve
any purpose.  My belief is that in practice, the requester is going
to be designed with quite a bit of knowledge about how the provider
behaves.  If it can't, or if the provider or the network is erratic,
then it will be designed to be fully asynchronous and probably specify
request ids.

But if it is an interactive application, it will be making synchronous
requests exclusively for which it expects a timely response. All current
usages of SPML with IDM are written this way for example.  Here request
ids are gratuitous and we'll be immediately asked to provide some
sort of automatic request id generator in the toolkit so they don't have
to bother with them.

I can understand why this would make the specification more concise, and that
may be reason enough to require them.   But I don't see where this makes
things any easier for the requester or the provider.  It makes it marginally
harder for the requester that only wants to make sync requests.

Jeff