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

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

Gary P Cole wrote:

> 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?


Primarily addRequest, deleteRequest, modifyRequest, and I suppose 
extendedRequest.
Then batchRequest since it can contain the others.

>
> 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.
>
Fine with me.

This touches on something I've never liked about 1.0.  The generic 
SpmlRequest class
has a "request id" which is normally used to specify the async id for 
the request.

But for statusRequest and cancelRequest we're overloading this to mean the
the id of some OTHER request rather than THIS request.

Now, as we've discussed it is sort of meaningless to have an 
asynchronous statusRequest
so the overloading doesn't in effect reduce any functionality.  Still, I 
dislike associating
two completely different semantics with the same attribute.  I would 
prefer for
status and cancel to have their own "targetRequestId".

Factoring the schema to separate "asyncable" requests would force this 
issue, since
presumably status/cancel would no longer inherit an async request id.


Jeff