Re: Async Conversion

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

For those of you following along at home, the issue before us is whether 
a provider may coerce to asynchronous execution: 1) *any* type of 
request or 2) only specific types of requests.

Mr. Larson is okay with #2.  He believes that only instances of 
BatchableRequestType (such as 'add', 'modify' and 'delete') and the 
BatchRequestType itself ('batch') should be convertible to asynchronous 
execution at the provider's initiative.  We can address this by defining 
an AsyncableRequestType, which BatchableRequestType and BatchRequestType 
could extend.
(Note that a custom request type could also extend AsyncableRequestType 
if the custom request should be convertible to asynchronous execution at 
a provider's initiative.)

The next question is whether we can live with the restriction that 
*only* an AsyncableRequestType can execute asynchronously.  (That is, a 
requestor can request asynchronous execution only for an instance of 
AsyncableRequestType).  This makes sense to me because 'add', 'modify', 
'delete' and (particularly) 'batch'  are the operations that I can 
imagine wanting to run asynchronously.

If we believe that *any* request type could be converted to asynchronous 
execution at a provider's initiative, or if we believe that a requestor 
should be able to request any type of operation asynchronously, then we 
should formalize a more general mechanism.  (I suggested such a 
mechanism earlier in this thread, but it's not worth discussing unless 
we have the need for it.)

gpc

Jeff Larson wrote:

> 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
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster 
> of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgroup.php. 
>
>