[
https://issues.apache.org/jira/browse/SHINDIG-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612695#action_12612695
]
John Hjelmstad commented on SHINDIG-442:
----------------------------------------
* Changing gadgets.rpc specification -- I'm unclear that's actually the case.
At present, the specification, as far as I've seen it, doesn't state anything
about inbound parameters that are functions. Meanwhile, the implementation just
weirdly serializes them.
* Nothing that can't be done with closures -- really? What this code is doing
is turning a function call on one side of the domain boundary into a
dynamically-generated remote callback that can (with syntactic sugar) be called
on the other. It does so for arbitrary function parameters, ie. more than just
the default supported for the return value of a given function.
I agree that all this can be done manually, but the idea is to make it easy to
provide ad-hoc continuations to gadgets.rpc calls. Zhen's proposal
(SHINDIG-441) adds asynchronicity as an option to the default callback, but
with somewhat funky semantics that depend on the calling context. That
proposal, IMHO, actually requires a spec change since it changes the semantics
of the callback (though in backward-compatible ways). The spec says, about the
callback:
"Function, null callback - Callback function (if any) to process the return
value of the RPC request"
That's no longer true if the alternate async mechanism is used, due to [EMAIL
PROTECTED]
* Multiple callbacks are still supported - just pass in multiple methods. As
implemented in this particular patch, each method is one-time-use, but that
doesn't prevent multiple methods from being passed in.
Adding markers to these remote callbacks indicating how they are timed
out/removed will, I agree, require a spec change (though again, a
backward-compatible one).
> 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.
