[jira] Closed: (SHINDIG-442) Remote callbacks functionality in gadgets.rpc

["John Hjelmstad (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SHINDIG-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Hjelmstad closed SHINDIG-442.
----------------------------------

    Resolution: Later

Closing as "Later".

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