[
https://issues.apache.org/jira/browse/SHINDIG-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612716#action_12612716
]
John Hjelmstad commented on SHINDIG-441:
----------------------------------------
As commented in SHINDIG-442, this changes how the callback function is used.
If we accept the premise that gadgets.rpc is _only_ for gadget-to-container
calls, and not the inverse, _and_ that the spec is only relevant to the gadgets
API and not the container-side, then I agree, this doesn't affect the spec.
Also as mentioned in that issue, I like this implementation, despite the
passing-by-context oddity. I just want to flesh out the boundaries of the spec
through this discussion (and the other too, I guess).
> Asynchronous rpc handler support
> --------------------------------
>
> Key: SHINDIG-441
> URL: https://issues.apache.org/jira/browse/SHINDIG-441
> Project: Shindig
> Issue Type: New Feature
> Components: Features (Javascript)
> Reporter: Zhen Wang
>
> Currently an gadget rpc handler must be synchronous. Its return value is
> immediately passed back to the rpc caller if a callback function is defined.
> This prevents an rpc request handler to make some asynchronous calls and
> return a value later.
> Proposed solution:
> Add a callback method to the rpc context object for an rpc request handler to
> return a value asynchronously.
> This won't affect existing code. Synchronous handlers may simply ignore the
> change and return a value as usual while async handlers don't return a value
> immediately and call "this.callback(return_value);" when ready.
> Patch to rpc.js:
> 232,236d231
> < if (rpc.c) {
> < rpc.callback = function(result) {
> < gadgets.rpc.call(rpc.f, CALLBACK_NAME, null, rpc.c, result);
> < };
> < }
> 242c237
> < if (rpc.c && typeof result != 'undefined') {
> ---
> > if (rpc.c) {
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
