[
https://issues.apache.org/jira/browse/SHINDIG-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612728#action_12612728
]
John Hjelmstad commented on SHINDIG-442:
----------------------------------------
Just thought about it a moment more, and came to the realization that in any
reasonable practice, RPC handlers will be an implementation detail rather than
subject to a particular API, so I've dropped the pedantry about Zhen's proposal.
Re: this one, in my view it basically fills in the blanks for what happens when
a function is passed to an RPC service - in particular, maintaining the
argument's "function-ness". Perhaps what this boils down to is that the spec
should indicate what happens.
Given that less-is-more in implementations, and that we should patch Zhen's
change irrespective whether this is deemed useful, I'm happy raising that
question on the spec mailing list rather than pushing this change right now. If
useful, it can be revisited.
> 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.
