[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [provision] Asynchronous requests.
Gary P Cole wrote: > > If we feel that it would be better for a client to communicate > *explicitly* which types of execution it can support, we might > consider 1) *requiring* the 'execution' attribute in a request, and 2) > adding a value of "either" to ExecutionType (in addition to its > current values of "synchronous" and "asynchronous"). I'm ok with an "either" ExecutionType, which in practice would be the only value we would ever use. Any request for synchronous execution would be an unconditional error because at the SPML layer we simply can't predict what's going to happen in the workflow. Approvals are dependent on arbitrarily complex logic which we won't know until we actually execute the workflow. As far as the client being prepared to handle an async request, I think this will always be the case. The client has to have some awareness of whether the PSP does workflow or not, otherwise it isn't going to be able to do anything since the PSP will throw back errors on every sync request. But let me state again that I don't think workflow semantics should be modeled using ExecutionType. The spec would be more useful if it formally modeled at least a few of the basic workflow concepts. The sync mode then applies only to the message protocol, not the time at which provisioning eventually happens. In many cases (ours certainly) the client doesn't really care if the request is queued pending approval, they just want to make sure the process is successfully started. In those cases, a synchronous request is convenient for the client. If we overload ExecutionType with workflow this forces the client to adopt an async-polling style of interface for EVERY request, even the ones that might be able to run synchronously. The "either" type addresses this, but it just feels strange to me. Jeff
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]