Async Conversion (was "Re: [provision] Re: Async and workflow")

[Gary P Cole <Gary.P.Cole@Sun.COM>]

Jeff Larson wrote:

> Yes, in SPML 1.0 it is just a client preference.  I brought it up 
> during the SPML 2.0 discussions, which
> led it to becoming something controlled by the PSP.  I haven't been 
> following the 2.0 spec that closely,
> so if this got dropped it needs to be brought up again.  The PSP must 
> be allowed to convert any
> synchronous request into an asynchronous request, and the RA needs to 
> be prepared to deal with it.

(I believe that this was dropped.) Could *any* type of request be 
converted to async at the provider's initiative?  Or does this apply 
only to specific types of requests?

If only specific types of requests can be converted to async at the 
provider's initiative, then perhaps we define something like a 
BatchableRequestType (e.g., a 
RequestTypeConvertibleToAsynchronousByProvider) that specific request 
types could extend.

If *any* request could be converted at the provider's initiative (which 
seems more general), then this should become a standard part of the 
protocol.  Any request should receive a synchronous response that MUST 
return a ResultCode and MAY return a requestID.  If the response#result 
is "pending", then the reponse must contain a requestID.  If the 
response#result is "failure", then the response must contain an "error" 
attribute.  If the response#result is "success", then the response must 
contain whatever result is appropriate to that type of request.

gpc