[
https://issues.apache.org/jira/browse/SHINDIG-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612656#action_12612656
]
Zhen Wang commented on SHINDIG-442:
-----------------------------------
This solution requires an rpc caller to pass null as the callback parameter to
gadget.rpc.call when it actually expects a callback. This creates confusion in
the semantics of function parameters.
Another implication is that rpc callers now need to call gadget.rpc.call in two
different ways depending on how an rpc handler processes requests. An rpc
caller shouldn't really care about whether the service handler is sync or
async. A more serious compatibility problem arises when all containers do not
implement an rpc service synchronously (or asynchronously.)
BTW, the attached patch doesn't actually allow multiple callbacks because of
rpc.js line 160.
> Remote callbacks functionality in gadgets.rpc
> ---------------------------------------------
>
> Key: SHINDIG-442
> URL: https://issues.apache.org/jira/browse/SHINDIG-442
> Project: Shindig
> Issue Type: Improvement
> Components: Features (Javascript)
> Reporter: John Hjelmstad
> Assignee: John Hjelmstad
> Priority: Minor
> Attachments: rpc.remotecallbacks.patch
>
>
> At present, passing a function as an argument to a gadgets.rpc service
> handler has undefined behavior (in practice, it probably stringifies the
> function in some odd ways).
> In order to support asynchronous callback of multiple methods, I propose
> automatically wrapping function parameters in "remote callbacks". This would
> allow something like the following:
> Service definition (as by container):
> function myServiceHandler(foo, onSuccess, onError) {
> var result = doSomethingWithFoo(foo);
> if (resultIsError(result)) {
> onError(result);
> } else {
> onSuccess(result);
> }
> }
> gadgets.rpc.register('my-service', myServiceHandler);
> Service use (as by gadget):
> gadgets.rpc.call('..', 'my-service', null, foo, function(result) { /* success
> code */ }, function(result) { /* error code */ });
> This allows intuitive definition of services using callbacks, and intuitive
> use of them in turn.
> This proposal is in many ways complementary to SHINDIG-441, as that proposal
> provides an async way to call the single "default" callback mechanism in
> gadgets.rpc. That there are two is somewhat confusing - there's an argument
> that having only one would be better, but since there's already a default I
> feel it's worthwhile to consider defining ad hoc versions.
> Pros:
> - Intuitive use of function arguments
> - Provides flexible asynchronous callback functionality to gadgets.rpc
> without changing any existing functionality
> Cons:
> - Somewhat conflated with "default" callback mechanism
> - Need to figure out memory-management policies for dynamically-generated
> remote callbacks.
> Regarding the latter, I propose later adding an optional API to mark remote
> callbacks with how long they last: oneTimeUse, timeoutInMs, etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
