[
https://issues.apache.org/jira/browse/SHINDIG-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612715#action_12612715
]
John Hjelmstad commented on SHINDIG-442:
----------------------------------------
Still confused. The spec doesn't mention _any_ semantics, not even for string
arguments, aside from: "Parameters for the RPC request." Presumably passing
these through in a meaningful way isn't particularly dangerous, particularly
since the very ability to handle a callback requires a remote callback service
to exist.
I get that Zhen's proposal doesn't affect the gadget side, _if_ all calls are
gadget-to-container. But there's nothing in the gadgets.rpc spec that enforces
that must be so. That's also just convention/current practice.
To be clear, I like both of these. But I think both brush the spec, and it's
worth fleshing out whether in either case this "brushing" is significant enough
to convert either or both of these to a spec proposal instead of an
implementation enhancement.
> 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.
