Add a cougar client batch interface

[eswdd]

No description provided.

[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.

[richardqd]

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 [email protected]
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
#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
#9 (comment).

[eswdd]

Yep
On 1 Dec 2014 13:50, "richardqd" [email protected] wrote:

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 <
[email protected]>
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
#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
#9 (comment).

—
Reply to this email directly or view it on GitHub
#9 (comment).

[richardqd]

Thing this is perfectly reasonable then!

On 1 December 2014 at 13:59, Simon Matic Langford [email protected]
wrote:

Yep
On 1 Dec 2014 13:50, "richardqd" [email protected] wrote:

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 <
[email protected]>
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
#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
#9 (comment).

—
Reply to this email directly or view it on GitHub
#9 (comment).

—
Reply to this email directly or view it on GitHub
#9 (comment).

[richardqd]

Think*

On 1 December 2014 at 14:12, Richard Mason [email protected] wrote:

Thing this is perfectly reasonable then!

On 1 December 2014 at 13:59, Simon Matic Langford <
[email protected]> wrote:

Yep
On 1 Dec 2014 13:50, "richardqd" [email protected] wrote:

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 <
[email protected]>
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
#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
#9 (comment).

—
Reply to this email directly or view it on GitHub
#9 (comment).

—
Reply to this email directly or view it on GitHub
#9 (comment).

[richardqd]

To me this is a reasonable step along one of the original design goals -
which may or may not ever be realised - of running a single cougar instance
that is like a giant proxy for all services. These days this function is
provided to external clients by API-NG, which provides access to >15 cougar
services.

On 1 December 2014 at 14:12, Richard Mason [email protected] wrote:

Think*

On 1 December 2014 at 14:12, Richard Mason [email protected] wrote:

Thing this is perfectly reasonable then!

On 1 December 2014 at 13:59, Simon Matic Langford <
[email protected]> wrote:

Yep
On 1 Dec 2014 13:50, "richardqd" [email protected] wrote:

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 <
[email protected]>
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
#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
#9 (comment).

—
Reply to this email directly or view it on GitHub
#9 (comment).

—
Reply to this email directly or view it on GitHub
#9 (comment).