richardqd
commented
9 years ago Hi Simon,
Have I understood correctly - you're saying that you can only address a single cougar endpoint with a client batch-call? Sounds reasonable to me
Richard.
On 1 December 2014 at 13:13, Simon Matic Langford notifications@github.com wrote:
Been thinking about this recently. Should offer sync and async interfaces. Suggested pattern:
On client have a call: void createNewBatchCall():BatchClientAsync.
Returned BatchClient interface has method for each method on interface, which either accepts an observer (async interface), or returns a typed future (sync interface).
It also has a makeBatchCall() method which fires off the batch call as an operation key with the Cougar service name (c.f. json rpc identity resolution) and the makeBatchCall method name (or some special key on the interface).
The call returns an exception if the client executable doesn't support batch calls (e.g. rescript).
The client then makes the calls and then calls observers/futures as responses are deserialised. We make no atomicity/transactional guarantees about batch calls, we make no promises on the order of completion of the individual method calls, except that all will have completed by the time the makeBatchCall() call returns (via async call back or sync callback).
If we make promise that all calls will go to the same Cougar endpoint then we will implement in socket and json-rpc clients (see #90 https://github.com/betfair/cougar/issues/90), if not then we can mimic batch call in current socket client (might be able to do this anyway). Suggest we make that guarantee.
— Reply to this email directly or view it on GitHub https://github.com/betfair/cougar/issues/9#issuecomment-65062520.
eswdd
Been thinking about this recently. Should offer sync and async interfaces. Suggested pattern:
On client have a call: void createNewBatchCall():BatchClient[Async](ExecutionContext, Timeout [, Observer]).
Returned BatchClient interface has method for each method on interface, which either accepts an observer (async interface), or returns a typed future (sync interface).
It also has a makeBatchCall() method which fires off the batch call as an operation key with the Cougar service name (c.f. json rpc identity resolution) and the makeBatchCall method name (or some special key on the interface).
The call returns an exception if the client executable doesn't support batch calls (e.g. rescript).
The client then makes the calls and then calls observers/futures as responses are deserialised. We make no atomicity/transactional guarantees about batch calls, we make no promises on the order of completion of the individual method calls, except that all will have completed by the time the makeBatchCall() call returns (via async call back or sync callback).
If we make promise that all calls will go to the same Cougar endpoint then we will implement in socket and json-rpc clients (see #90), if not then we can mimic batch call in current socket client (might be able to do this anyway). Suggest we make that guarantee.