[jira] Updated: (SHINDIG-410) Refactor gadgets.rpc for cleaner handling of transport types

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

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

John Hjelmstad updated SHINDIG-410:
-----------------------------------

    Description: 
[repurposing this bug as refactoring-only]

Joey Schorr and I have created the attached patch to features/rpc/rpc.js, which refactors rpc.js in various ways but changes no semantics. The goal is to make reading of the code more straightforward, and especially to clearly separate code paths that have to do with the various message passing transport mechanisms (frameElement, IFPC, WPM/DPM). This makes it easier to add new transports. It may also, in the future, enable us to serve only one transport class appropriate to a given browser on the server side, minimizing response size, but for now is just cleanup.

Details:
* Created constants for the default callback and callback service IDs
* Added extensive documentation on each transport mechanism in the selection method getRelayChannel()
* Created setupChannel(), setupFrame(), and callX() methods for transport-specific functionality.
  - setupChannel() performs global initialization of the transport
  - setupFrame() adds any setup associated with setting authToken on a frame
  - callX() methods perform actual message passing

The attached patch (rpc.refactor.patch) is derived from an earlier, larger one that also included a new transport mechanism for IE only. That functionality will be moved to a new JIRA issue with a separate patch.

  was:
Take 2 :)

I've been working on a new technique for cross-domain communication in IE that exploits the fact that window.opener can be set and read across domains. To secure this, VBScript object wrappers are used. The technique is a little crazy, but maintains object isolation while utilizing the existing authToken-based security mechanism for establishing a communication channel and authenticating messages sent from gadget to container and back.

See attached patch for details.

        Summary: Refactor gadgets.rpc for cleaner handling of transport types  (was: Consider refactoring + NIX (Native IE XDC) enhancement)

> Refactor gadgets.rpc for cleaner handling of transport types
> ------------------------------------------------------------
>
>                 Key: SHINDIG-410
>                 URL: https://issues.apache.org/jira/browse/SHINDIG-410
>             Project: Shindig
>          Issue Type: Improvement
>          Components: Features (Javascript)
>         Environment: All
>            Reporter: John Hjelmstad
>            Assignee: John Hjelmstad
>         Attachments: rpc.refactor.patch
>
>
> [repurposing this bug as refactoring-only]
> Joey Schorr and I have created the attached patch to features/rpc/rpc.js, which refactors rpc.js in various ways but changes no semantics. The goal is to make reading of the code more straightforward, and especially to clearly separate code paths that have to do with the various message passing transport mechanisms (frameElement, IFPC, WPM/DPM). This makes it easier to add new transports. It may also, in the future, enable us to serve only one transport class appropriate to a given browser on the server side, minimizing response size, but for now is just cleanup.
> Details:
> * Created constants for the default callback and callback service IDs
> * Added extensive documentation on each transport mechanism in the selection method getRelayChannel()
> * Created setupChannel(), setupFrame(), and callX() methods for transport-specific functionality.
>   - setupChannel() performs global initialization of the transport
>   - setupFrame() adds any setup associated with setting authToken on a frame
>   - callX() methods perform actual message passing
> The attached patch (rpc.refactor.patch) is derived from an earlier, larger one that also included a new transport mechanism for IE only. That functionality will be moved to a new JIRA issue with a separate patch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.