Details

    • Type: Technical task Technical task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.1-INCUBATING
    • Fix Version/s: 0.11
    • Component/s: None
    • Labels:
      None

      Description

      Make the RAVE portal support inter-gadget communications among OpenSocial gadgets (do NOT include W3C widgets).

      The goal is to support OpenSocial pub/sub APIs (http://opensocial-resources.googlecode.com/svn/spec/2.0/Core-Gadget.xml#interGadgetEventing).

      1. rave_wookie.js
        4 kB
        Scott Wilson
      2. openajax.wgt
        16 kB
        Scott Wilson

        Issue Links

          Activity

          Hide
          Scott Wilson added a comment -

          D'oh!

          Thanks for taking the time to dig into this one Matt, I was sort of hoping it was actually something simple. I'll complete the rest of rave-wookie.js and commit it.

          Show
          Scott Wilson added a comment - D'oh! Thanks for taking the time to dig into this one Matt, I was sort of hoping it was actually something simple. I'll complete the rest of rave-wookie.js and commit it.
          Hide
          Matt Franklin added a comment -

          So after a bunch of digging, it turns out that they just used the reference implementation and added a few lines that should not impact the operation of the hub. Most of the errors you are seeing are due to the fact that you are passing an integer as the container id instead of a string. When I changed that in the code, I was able to get everything to work properly.

          Also, if you modify your widget to publish on the org.apache.shindig.random-number topic, you can see it interact with the opensocial gadgets that are in the store.

          Show
          Matt Franklin added a comment - So after a bunch of digging, it turns out that they just used the reference implementation and added a few lines that should not impact the operation of the hub. Most of the errors you are seeing are due to the fact that you are passing an integer as the container id instead of a string. When I changed that in the code, I was able to get everything to work properly. Also, if you modify your widget to publish on the org.apache.shindig.random-number topic, you can see it interact with the opensocial gadgets that are in the store.
          Hide
          Scott Wilson added a comment -

          Attached - note its not complete, I just wanted to get a basic OpenAjax iframe working

          Show
          Scott Wilson added a comment - Attached - note its not complete, I just wanted to get a basic OpenAjax iframe working
          Hide
          Matt Franklin added a comment -

          It would also help to have your updated rave-wookie.js

          Show
          Matt Franklin added a comment - It would also help to have your updated rave-wookie.js
          Hide
          Matt Franklin added a comment -

          Got it. Thanks. BTW, that wookie catalog lookup is slick.

          Show
          Matt Franklin added a comment - Got it. Thanks. BTW, that wookie catalog lookup is slick.
          Hide
          Scott Wilson added a comment -

          Ah that makes sense.

          I've attached the test W3C widget - you can drop it into /wookie/deploy and add it through the Rave web interface. As you can see its really just the example client from the OA website including the 2.0.7 reference js.

          S

          Show
          Scott Wilson added a comment - Ah that makes sense. I've attached the test W3C widget - you can drop it into /wookie/deploy and add it through the Rave web interface. As you can see its really just the example client from the OA website including the 2.0.7 reference js. S
          Hide
          Matt Franklin added a comment -

          I dug into this and it looks like the developer of this Shindig feature didn't use a reference implementation and re-implemented the spec. What you see here isn't as much of a deep dependency on Shindig's stack but a core assumption that the only containers would be housed in gadgets.

          I will dig a bit deeper, but I think we patch Shindig to remove this assumption from the code. The hub looks like it is pretty compliant other than that. Unless anyone else really wants to dig into this code, I will try and see if I can't get something working before 0.11.

          Can you commit the W3C widget (including Rave db entries) you wrote so that I can test?

          Show
          Matt Franklin added a comment - I dug into this and it looks like the developer of this Shindig feature didn't use a reference implementation and re-implemented the spec. What you see here isn't as much of a deep dependency on Shindig's stack but a core assumption that the only containers would be housed in gadgets. I will dig a bit deeper, but I think we patch Shindig to remove this assumption from the code. The hub looks like it is pretty compliant other than that. Unless anyone else really wants to dig into this code, I will try and see if I can't get something working before 0.11. Can you commit the W3C widget (including Rave db entries) you wrote so that I can test?
          Hide
          Scott Wilson added a comment -

          OK, I had a go at implementing for rave-wookie, with:

          var ooacontainer = new OpenAjax.hub.IframeContainer(rave.getManagedHub() , widget.regionWidgetId,
          {
          Container:

          { onSecurityAlert: onClientSecurityAlert, onConnect: onClientConnect, onDisconnect: onClientDisconnect }

          ,
          IframeContainer: {
          parent: widgetBodyElement,
          iframeAttrs: { style: { width:"100%"}},
          uri: widget.widgetUrl
          }
          }
          );

          ... and a test widget including OpenAjaxManagedHub-all.js and using the example client code off the OA site.

          However when I open in Rave I get:

          TypeError: 'undefined' is not a function (evaluating 'gadgetId.charAt(0)') container:pubsub-2.js:11002
          TypeError: 'undefined' is not a function (evaluating 'window[params.IframeContainer.onGadgetLoad]()') container:pubsub-2.js:4430
          TypeError: 'undefined' is not a function (evaluating 'targetId.charAt(0)') container:pubsub-2.js:4430

          I suspect this may be because rave.getManagedHub() has some deep dependencies on the rest of the shindig stack, especially its RPC services, in which case it can't be generalised to other widget types

          Or maybe I just got the parameters wrong?

          Show
          Scott Wilson added a comment - OK, I had a go at implementing for rave-wookie, with: var ooacontainer = new OpenAjax.hub.IframeContainer(rave.getManagedHub() , widget.regionWidgetId, { Container: { onSecurityAlert: onClientSecurityAlert, onConnect: onClientConnect, onDisconnect: onClientDisconnect } , IframeContainer: { parent: widgetBodyElement, iframeAttrs: { style: { width:"100%"}}, uri: widget.widgetUrl } } ); ... and a test widget including OpenAjaxManagedHub-all.js and using the example client code off the OA site. However when I open in Rave I get: TypeError: 'undefined' is not a function (evaluating 'gadgetId.charAt(0)') container:pubsub-2.js:11002 TypeError: 'undefined' is not a function (evaluating 'window [params.IframeContainer.onGadgetLoad] ()') container:pubsub-2.js:4430 TypeError: 'undefined' is not a function (evaluating 'targetId.charAt(0)') container:pubsub-2.js:4430 I suspect this may be because rave.getManagedHub() has some deep dependencies on the rest of the shindig stack, especially its RPC services, in which case it can't be generalised to other widget types Or maybe I just got the parameters wrong?
          Hide
          Matt Franklin added a comment -

          I have created an OpenAjax Hub instance in rave and passed this instance to the Shindig CommonContainer in rave-opensocial. rave-wookie (or any widget provider) can now acces and use the hub via rave.getManagedHub()

          Show
          Matt Franklin added a comment - I have created an OpenAjax Hub instance in rave and passed this instance to the Shindig CommonContainer in rave-opensocial. rave-wookie (or any widget provider) can now acces and use the hub via rave.getManagedHub()
          Hide
          Matt Franklin added a comment -

          I was planning to use OpenAJAX as you suggested earlier....Didn't know the ROLE guys were using something else.

          Unless anyone objects, I think starting with OpenAjax and moving to something else later, if it makes sense, is the best path.

          Show
          Matt Franklin added a comment - I was planning to use OpenAJAX as you suggested earlier....Didn't know the ROLE guys were using something else. Unless anyone objects, I think starting with OpenAjax and moving to something else later, if it makes sense, is the best path.
          Hide
          Scott Wilson added a comment -

          Are we going with OpenAjax hub for IWC in Rave, or putting in the OpenApp stuff from ROLE? Or both?

          (In any case we should probably change the subject of the issue to "Implement Rave inter-widget messaging". )

          Show
          Scott Wilson added a comment - Are we going with OpenAjax hub for IWC in Rave, or putting in the OpenApp stuff from ROLE? Or both? (In any case we should probably change the subject of the issue to "Implement Rave inter-widget messaging". )
          Hide
          Zhenhua (Gerald) Guo added a comment -

          Wrote some gadgets that use OpenSocial pub/sub APIs. But they did not work in RAVE. I need to figure out the cause. So I changed the assignee to "unassigned" to not block others who may want to resolve it as well.

          Show
          Zhenhua (Gerald) Guo added a comment - Wrote some gadgets that use OpenSocial pub/sub APIs. But they did not work in RAVE. I need to figure out the cause. So I changed the assignee to "unassigned" to not block others who may want to resolve it as well.
          Hide
          Matt Franklin added a comment -

          I agree that integrating OpenAjax Hub into Rave then wiring up to OpenSocial is probably the way to go. We want to make sure that the Rave inter-widget messaging is agnostic to any underlying widget provider's communication method.

          What I was trying to say with the top level issue is that the various widget providers (rave_opensocial, rave_foo) should be able to proxy and translate from their own internal implementations of inter-widget communication to the rave implementation, so that we can support cross-widget-type messaging without modifying too much.

          Show
          Matt Franklin added a comment - I agree that integrating OpenAjax Hub into Rave then wiring up to OpenSocial is probably the way to go. We want to make sure that the Rave inter-widget messaging is agnostic to any underlying widget provider's communication method. What I was trying to say with the top level issue is that the various widget providers (rave_opensocial, rave_foo) should be able to proxy and translate from their own internal implementations of inter-widget communication to the rave implementation, so that we can support cross-widget-type messaging without modifying too much.
          Hide
          Scott Wilson added a comment -

          OK - though it seems it would be easier to add generic OpenAjax Hub integration and then wire it up to OpenSocial rather than the other way around; the OS-specific extensions look pretty simple.

          W3C doesn't specify a particular pubsub or rpc mechanism; however it has a very similar <feature> extension mechanism to OS so if OpenAjax Hub pubsub is the preferred inter-widget solution it can be added easily enough in Wookie.

          At the container level it would just be a case of identifying the object to check for before calling functions - e.g. "gadgets.Hub" vs (say) "events.Hub" or "widget.Hub"

          Show
          Scott Wilson added a comment - OK - though it seems it would be easier to add generic OpenAjax Hub integration and then wire it up to OpenSocial rather than the other way around; the OS-specific extensions look pretty simple. W3C doesn't specify a particular pubsub or rpc mechanism; however it has a very similar <feature> extension mechanism to OS so if OpenAjax Hub pubsub is the preferred inter-widget solution it can be added easily enough in Wookie. At the container level it would just be a case of identifying the object to check for before calling functions - e.g. "gadgets.Hub" vs (say) "events.Hub" or "widget.Hub"
          Hide
          Zhenhua (Gerald) Guo added a comment -

          OpenSocial spec includes support for pubsub APIs (based on OpenAjax Hub APIs, but more simple). The APIs are in the spec, which means they can be used/run across opensocial containers.
          The goal of this issue is to verify that OpenSocial pubsub APIs (not OpenAjax Hub APIs) work correctly.

          In the long run, we will add generic OpenAjax Hub API support which will enable communications between OpenSocial gadgets and W3C widgets.

          BTW, in W3C widget spec, is there any support for inter-widget communication (pubsub, or rpc, etc)?

          Show
          Zhenhua (Gerald) Guo added a comment - OpenSocial spec includes support for pubsub APIs (based on OpenAjax Hub APIs, but more simple). The APIs are in the spec, which means they can be used/run across opensocial containers. The goal of this issue is to verify that OpenSocial pubsub APIs (not OpenAjax Hub APIs) work correctly. In the long run, we will add generic OpenAjax Hub API support which will enable communications between OpenSocial gadgets and W3C widgets. BTW, in W3C widget spec, is there any support for inter-widget communication (pubsub, or rpc, etc)?
          Hide
          Scott Wilson added a comment -

          There isn't anything inherently OpenSocial-specific about OpenAjax Hub pubsub; restricting it to just that set of widgets seems like additional work to reduce its value rather than enhance it.

          Show
          Scott Wilson added a comment - There isn't anything inherently OpenSocial-specific about OpenAjax Hub pubsub; restricting it to just that set of widgets seems like additional work to reduce its value rather than enhance it.

            People

            • Assignee:
              Matt Franklin
              Reporter:
              Zhenhua (Gerald) Guo
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development