Shindig
  1. Shindig
  2. SHINDIG-1330

Incorporate OpenAjax Hub as Pub-Sub Mechanism for Shindig (Open Social 1.next)

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0
    • Fix Version/s: 2.0.0
    • Component/s: Javascript
    • Labels:
      None
    • Environment:
      Shindig trunk.
      Java 5
      Windows
      FireFox, Safari, Chrome

      Description

      This patch is an initial alpha implementation by Javier Pedemonte (OpenAjaxHub/IBM) based on the proposal described here
      http://wiki.opensocial.org/index.php?title=Incorporate_Open_Ajax_Hub_as_Pub-Sub_Mechanism_for_OpenSocial_1.next
      While there are still more work, the patch provides a new pubsub feature which uses OAHub as the underlying eventing model.
      The /content/container/sample-pubsub-2.html demonstrates a simple pubsub example using the feature.
      API documentation can be found in the comments of the /javascript/features/pubsub-2/pubsub-2.js

      1. pubsub2.patch
        118 kB
        Han Nguyen

        Issue Links

          Activity

          Hide
          Paul Lindner added a comment -

          Hi Han,

          Can you upload this to codereview.appspot.com?

          I think that having some review would be useful, plus there may be better ways of accomplishing what you're trying to do.

          Thanks!

          Show
          Paul Lindner added a comment - Hi Han, Can you upload this to codereview.appspot.com? I think that having some review would be useful, plus there may be better ways of accomplishing what you're trying to do. Thanks!
          Hide
          Javier Pedemonte added a comment -

          Update patch and description: http://codereview.appspot.com/1247044/show

          Show
          Javier Pedemonte added a comment - Update patch and description: http://codereview.appspot.com/1247044/show
          Hide
          Kai Feng Zhang added a comment -

          I am working on some project which need to use shindig as a reference. But I find I can not see the pubsub sample work fine within Shindig 1.1-BETA5, neither in Shindig 2.0.

          This was once dicussed by here:
          http://mail-archives.apache.org/mod_mbox/shindig-dev/201005.mbox/<AANLkTimw9GNKzGb_ARQEV1THVyPH_tM8dUO9XLlVB7nP@mail.gmail.com>

          If I apply the patch provided in this bug to 2.0 Shindig, the new pubsub sample(pubsub2) works fine. But the original pubsub sample does not work still.

          My question is:
          1) Did the pubsub sample once work in some Shindig version?
          2) Does the new patch use same underlying API as the original pubsub API?

          Thanks.

          Show
          Kai Feng Zhang added a comment - I am working on some project which need to use shindig as a reference. But I find I can not see the pubsub sample work fine within Shindig 1.1-BETA5, neither in Shindig 2.0. This was once dicussed by here: http://mail-archives.apache.org/mod_mbox/shindig-dev/201005.mbox/ <AANLkTimw9GNKzGb_ARQEV1THVyPH_tM8dUO9XLlVB7nP@mail.gmail.com> If I apply the patch provided in this bug to 2.0 Shindig, the new pubsub sample(pubsub2) works fine. But the original pubsub sample does not work still. My question is: 1) Did the pubsub sample once work in some Shindig version? 2) Does the new patch use same underlying API as the original pubsub API? Thanks.
          Hide
          Han Nguyen added a comment -

          I don't see this pubsub2 feature applied in Shinding2.0-RC1. What need to be done to get this patch applied for Shindig 2.0 release?

          Show
          Han Nguyen added a comment - I don't see this pubsub2 feature applied in Shinding2.0-RC1. What need to be done to get this patch applied for Shindig 2.0 release?
          Hide
          Javier Pedemonte added a comment -

          Kai:

          I have updated the patch (on codereview) to fix the 'pubsub' sample.

          In response to (2), this patch uses OpenAjax Hub to do the pubsub events and as such implements a new API. See the comments at the top of pubsub-2.js and pubsub-2-router.js.

          Show
          Javier Pedemonte added a comment - Kai: I have updated the patch (on codereview) to fix the 'pubsub' sample. In response to (2), this patch uses OpenAjax Hub to do the pubsub events and as such implements a new API. See the comments at the top of pubsub-2.js and pubsub-2-router.js.
          Hide
          Javier Pedemonte added a comment -

          STATUS OF LATEST PATCH (SET #4)

          • Adds new pubsub-2 feature.
          • Adds the following new APIs:
          • gadgets.byId()
          • gadgets.rpc.config()
          • For setting config parameters on rpc connection. Right now only
            takes a security callback.
          • gadgets.rpc.removeReceiver()
          • gadgets.rpc.getReceiverOrigin()
          • Updated NIX transport to support parent verification, given a valid relay file.
          • Updated WPM transport to check origin on message reception. Also added checks for non-async WPM and Opera 9.x's use of "event.domain" instead of "event.origin".
          • Hook for possible frame phishing in rpc.js, given a valid relay file.

          QUESTIONS/REMAINING ISSUES

          • Not sure of the best place to put gadgets.byId(). For now, I've put it in core.util/util.js, but that needs to be fixed.
          • In shindig-container.js, since OpenAjax Hub creates the iframe, needed to split code up into two cases: the case where gadget requires the 'pubsub-2' feature and therefore uses OAA Hub to create and manage the iframe; and the existing case where the iframe is created in shindig-container.js. This code isn't pretty, since I need to do a metadata request for the gadget. Ideally, I should be using the new container code (the 'shindig.container-1.0' feature), since it fetches and caches the gadget metadata on the container side. Will this new container code be the default container for Shindig 2.0?
          • Not sure about gadgets.rpc.config(). Need a way to set the security callback function. In a previous discussion, we decided to go with config() rather than a function specifically for the callback (see http://wiki.opensocial.org/index.php?title=PubSub.next_Proposals#Secure_rpc), since we could expand it in the future for other uses.
          Show
          Javier Pedemonte added a comment - STATUS OF LATEST PATCH (SET #4) Adds new pubsub-2 feature. Adds the following new APIs: gadgets.byId() gadgets.rpc.config() For setting config parameters on rpc connection. Right now only takes a security callback. gadgets.rpc.removeReceiver() gadgets.rpc.getReceiverOrigin() Updated NIX transport to support parent verification, given a valid relay file. Updated WPM transport to check origin on message reception. Also added checks for non-async WPM and Opera 9.x's use of "event.domain" instead of "event.origin". Hook for possible frame phishing in rpc.js, given a valid relay file. QUESTIONS/REMAINING ISSUES Not sure of the best place to put gadgets.byId(). For now, I've put it in core.util/util.js, but that needs to be fixed. In shindig-container.js, since OpenAjax Hub creates the iframe, needed to split code up into two cases: the case where gadget requires the 'pubsub-2' feature and therefore uses OAA Hub to create and manage the iframe; and the existing case where the iframe is created in shindig-container.js. This code isn't pretty, since I need to do a metadata request for the gadget. Ideally, I should be using the new container code (the 'shindig.container-1.0' feature), since it fetches and caches the gadget metadata on the container side. Will this new container code be the default container for Shindig 2.0? Not sure about gadgets.rpc.config(). Need a way to set the security callback function. In a previous discussion, we decided to go with config() rather than a function specifically for the callback (see http://wiki.opensocial.org/index.php?title=PubSub.next_Proposals#Secure_rpc ), since we could expand it in the future for other uses.
          Hide
          Javier Pedemonte added a comment -

          ANOTHER ISSUE: The update to NIX to support parent verification requires two auth tokens: one from the parent and one from the child. The code I wrote just generates a random token on the child side. What would be the best way to allow a gadget to provide this auth token? Given that RPC initializes the connection to the parent when rpc.js is evaled, the child auth token cannot be provided on gadget load (it's too late). Perhaps there is no good solution and we'll just use a randomly generated child token?

          Show
          Javier Pedemonte added a comment - ANOTHER ISSUE: The update to NIX to support parent verification requires two auth tokens: one from the parent and one from the child. The code I wrote just generates a random token on the child side. What would be the best way to allow a gadget to provide this auth token? Given that RPC initializes the connection to the parent when rpc.js is evaled, the child auth token cannot be provided on gadget load (it's too late). Perhaps there is no good solution and we'll just use a randomly generated child token?
          Hide
          Kien Nguyen added a comment -

          Hi, I also work with shindig in my project, but i can't run pubsub function.
          Please give me advice any released shindig version that pubsub worked

          Show
          Kien Nguyen added a comment - Hi, I also work with shindig in my project, but i can't run pubsub function. Please give me advice any released shindig version that pubsub worked
          Hide
          Paul Lindner added a comment -

          it's in!

          Show
          Paul Lindner added a comment - it's in!
          Hide
          Ilya Shtein added a comment -

          I am working on a portal framework, which allows to include Shindig-rendered gadgets into enterprise applications. We are also required to allow these Applications to interact with Gadgets by sending / receiving notifications. We decided to implement this mechanism using OpenAjax Hub. It plays extremely well with the PubSub-2 implementation, and I already did a proof-of-concept on this.
          The only issue I have is that on the Applicaiton side the preferred implementation is based on TIBCO version of OpenAjax Hub (due to its caching feature), and not on the reference implementation, as PubSub-2 is. Can you please suggest an approach to resolve this.

          Show
          Ilya Shtein added a comment - I am working on a portal framework, which allows to include Shindig-rendered gadgets into enterprise applications. We are also required to allow these Applications to interact with Gadgets by sending / receiving notifications. We decided to implement this mechanism using OpenAjax Hub. It plays extremely well with the PubSub-2 implementation, and I already did a proof-of-concept on this. The only issue I have is that on the Applicaiton side the preferred implementation is based on TIBCO version of OpenAjax Hub (due to its caching feature), and not on the reference implementation, as PubSub-2 is. Can you please suggest an approach to resolve this.
          Hide
          Kevin Parkerson added a comment -

          Hi there, I too am working on a portal framework that uses Shindig to allow third party developers to create gadgets for our service. I was wanting to experiment with these new pubsub controls, but for some reason all patches beyond patch set 2 don't seem to do anything when attempting to apply them via tortoise svn. Is there something I'm missing here? Anybody else experiencing issues with these patches? Any help with this would be greatly appreciated.

          Show
          Kevin Parkerson added a comment - Hi there, I too am working on a portal framework that uses Shindig to allow third party developers to create gadgets for our service. I was wanting to experiment with these new pubsub controls, but for some reason all patches beyond patch set 2 don't seem to do anything when attempting to apply them via tortoise svn. Is there something I'm missing here? Anybody else experiencing issues with these patches? Any help with this would be greatly appreciated.
          Hide
          Han Nguyen added a comment -

          @ Kevin Parkerson, I'm not sure which version of Shindig you're using. This patch has been applied to Shindig2.0.0 release and should be in Shindig trunk as well. Perhaps, upgrading to the latest release to leverage the feature?

          Show
          Han Nguyen added a comment - @ Kevin Parkerson, I'm not sure which version of Shindig you're using. This patch has been applied to Shindig2.0.0 release and should be in Shindig trunk as well. Perhaps, upgrading to the latest release to leverage the feature?
          Hide
          Kevin Parkerson added a comment -

          @Han Nguyen, thank you for the quick reply. I've been using the Shindig 2.0.0 release for a while now through tomcat, using the shindig-server-2.0.0.war file provided from http://shindig.apache.org/download/index.html. Oddly enough, I'm not seeing the pubsub-2 feature inside the shindig-features-2.0.0.jar... it should be listed inside the ...\shindig-features-2.0.0\features\ directory right? Either way it helps to know the patches have been applied to the latest version, so thanks again for that information.

          Show
          Kevin Parkerson added a comment - @Han Nguyen, thank you for the quick reply. I've been using the Shindig 2.0.0 release for a while now through tomcat, using the shindig-server-2.0.0.war file provided from http://shindig.apache.org/download/index.html . Oddly enough, I'm not seeing the pubsub-2 feature inside the shindig-features-2.0.0.jar... it should be listed inside the ...\shindig-features-2.0.0\features\ directory right? Either way it helps to know the patches have been applied to the latest version, so thanks again for that information.
          Hide
          Han Nguyen added a comment -

          @ Kevin Parkerson, pubsub-2 is added under /features-extras. If you're running shindig2.0.0 war, then the example below should work
          http://<server:port>/container/sample-pubsub-2.html

          Show
          Han Nguyen added a comment - @ Kevin Parkerson, pubsub-2 is added under /features-extras. If you're running shindig2.0.0 war, then the example below should work http://<server:port>/container/sample-pubsub-2.html
          Hide
          Kevin Parkerson added a comment -

          @Han Nguyen oh wow, why I never thought to look outside of shindig-features-2.0.0.jar is a mystery... must be a case of "Friday stupidity"... thanks for the help!

          Show
          Kevin Parkerson added a comment - @Han Nguyen oh wow, why I never thought to look outside of shindig-features-2.0.0.jar is a mystery... must be a case of "Friday stupidity"... thanks for the help!
          Hide
          Kevin Parkerson added a comment -

          Hi there, me again. Nice work on the pubsub-2 feature, we've used it to successfully accomplish many of our goals on an application running within the Tomcat ROOT directory. However, when trying to run our application outside ROOT, we are getting an interesting error upon gadget rendering that looks something like this:

          POST http://localhost/gadgets/metadata?st=john.doe:john.doe:appid:cont:url:0:defaultPOST http://localhost/gadgets/metadata?st=john.doe:john.doe:appid:cont:url:0:default404 Not Found 45ms

          The application is .NET 4.0 on a Windows machine running IIS 7 and the containers are calling into shindig. IIS is doing the following with the request:

          Requested URL: http://localhost:80/gadgets/metadata?st=john.doe:john.doe:appid:cont:url:0:default --> Physical Path: D:\Inetpub\gadgets\metadata

          Is there some way to bypass getting the metadata? We've already tried setServerBase and it doesn't seem to work correctly. Any help would be greatly appreciated. Thanks in advance!

          Show
          Kevin Parkerson added a comment - Hi there, me again. Nice work on the pubsub-2 feature, we've used it to successfully accomplish many of our goals on an application running within the Tomcat ROOT directory. However, when trying to run our application outside ROOT, we are getting an interesting error upon gadget rendering that looks something like this: POST http://localhost/gadgets/metadata?st=john.doe:john.doe:appid:cont:url:0:defaultPOST http://localhost/gadgets/metadata?st=john.doe:john.doe:appid:cont:url:0:default404 Not Found 45ms The application is .NET 4.0 on a Windows machine running IIS 7 and the containers are calling into shindig. IIS is doing the following with the request: Requested URL: http://localhost:80/gadgets/metadata?st=john.doe:john.doe:appid:cont:url:0:default --> Physical Path: D:\Inetpub\gadgets\metadata Is there some way to bypass getting the metadata? We've already tried setServerBase and it doesn't seem to work correctly. Any help would be greatly appreciated. Thanks in advance!
          Hide
          Han Nguyen added a comment -

          @ Kevin,

          How do you change Shindig context root, specifically the serverBase value set in the function of shindig-container.js below?
          shindig.BaseIfrGadget = function(opt_params)

          { shindig.Gadget.call(this, opt_params); this.serverBase_ = '/gadgets/'; // default gadget server this.queryIfrGadgetType_(); }

          ;

          Looks like serverBase value is hardcoded to '/gadgets/', and we don't know how it can be dynamically set, but we've learned that if it's not updated with the context root
          accordingly then the gadget won't be rendered, is that what you're experiencing?
          setServerBase() won't help in this case because 1. the above function is invoked prior setServerBase() and 2. this.serverBase is hardcoded in that function.

          So to get around, we currently set serverBase as opt_params when creating a gadget. For example: with "/shindig" as a context root, we create gadget0 as follow
          var gadget0 = shindig.container.createGadget(

          {specUrl: 'http://www.google.com/ig/modules/horoscope.xml', serverBase: '/shindig/gadgets/'}

          );
          Then, we modified shindig.BaseIfrGadget = function(opt_params) in shindig-container.js so it will set the serverBase from the opt_params input

          shindig.BaseIfrGadget = function(opt_params) {
          shindig.Gadget.call(this, opt_params);
          if(opt_params.serverBase)

          { this.serverBase_ = opt_params.serverBase; }

          else

          { this.serverBase_ = '/gadgets/'; // default gadget server }

          this.queryIfrGadgetType_();
          };

          Alternatively, you can hard code the context root "/shindig" in the serverBase value as seen here

          shindig.BaseIfrGadget = function(opt_params)

          { shindig.Gadget.call(this, opt_params); this.serverBase_ = '/shindig/gadgets/'; // default gadget server this.queryIfrGadgetType_(); }

          ;

          I think the question is left for anyone who knows how to update the context root value in the function above dynamically. Let us know if that helps.

          Javier, do you have other insight for this?

          Han

          Show
          Han Nguyen added a comment - @ Kevin, How do you change Shindig context root, specifically the serverBase value set in the function of shindig-container.js below? shindig.BaseIfrGadget = function(opt_params) { shindig.Gadget.call(this, opt_params); this.serverBase_ = '/gadgets/'; // default gadget server this.queryIfrGadgetType_(); } ; Looks like serverBase value is hardcoded to '/gadgets/', and we don't know how it can be dynamically set, but we've learned that if it's not updated with the context root accordingly then the gadget won't be rendered, is that what you're experiencing? setServerBase() won't help in this case because 1. the above function is invoked prior setServerBase() and 2. this.serverBase is hardcoded in that function. So to get around, we currently set serverBase as opt_params when creating a gadget. For example: with "/shindig" as a context root, we create gadget0 as follow var gadget0 = shindig.container.createGadget( {specUrl: 'http://www.google.com/ig/modules/horoscope.xml', serverBase: '/shindig/gadgets/'} ); Then, we modified shindig.BaseIfrGadget = function(opt_params) in shindig-container.js so it will set the serverBase from the opt_params input shindig.BaseIfrGadget = function(opt_params) { shindig.Gadget.call(this, opt_params); if(opt_params.serverBase) { this.serverBase_ = opt_params.serverBase; } else { this.serverBase_ = '/gadgets/'; // default gadget server } this.queryIfrGadgetType_(); }; Alternatively, you can hard code the context root "/shindig" in the serverBase value as seen here shindig.BaseIfrGadget = function(opt_params) { shindig.Gadget.call(this, opt_params); this.serverBase_ = '/shindig/gadgets/'; // default gadget server this.queryIfrGadgetType_(); } ; I think the question is left for anyone who knows how to update the context root value in the function above dynamically. Let us know if that helps. Javier, do you have other insight for this? Han
          Hide
          Kevin Parkerson added a comment -

          @Han,

          Ah yes, modifying the function within shindig.container.js does the trick! We were trying to override shindig.BaseIfrGadget in a separate script on the page itself, but for some reason it wasn't taking. Dynamically modifying the serverBase would be nice, but for now the method you've suggested will be just fine. Thanks again for the help!

          Show
          Kevin Parkerson added a comment - @Han, Ah yes, modifying the function within shindig.container.js does the trick! We were trying to override shindig.BaseIfrGadget in a separate script on the page itself, but for some reason it wasn't taking. Dynamically modifying the serverBase would be nice, but for now the method you've suggested will be just fine. Thanks again for the help!
          Hide
          Han Nguyen added a comment -

          Good to hear Kevin. I'll open a bug if there's no suggestion on how to set the value dynamically BOD.
          Han

          Show
          Han Nguyen added a comment - Good to hear Kevin. I'll open a bug if there's no suggestion on how to set the value dynamically BOD. Han
          Hide
          Kevin Parkerson added a comment -

          Hi there,

          I have yet another question for your team. Thus far we've been using the default gadget rendering methods (shindig.container.createGadget, shindig.container.addGadget, and ashindig.container.renderGadget) in order to utilize the pubsub-2 feature. However, we would like to be able to render gadgets programmatically by generating the url as specified on https://cwiki.apache.org/confluence/display/SHINDIG/iframe+url+format and setting it to the src element of an iframe. We've done this in the past and features such as RPC, tabs, and the old pubsub mechanism worked without problem, but because pubsub-2 changes how the gadgets are rendered it seems they cannot utilize the new pubsub-2 feature. I assume this is the result of not registering the appropriate values with the Shindig/OAA gadget framework. Is there a way to add programmatically created gadgets to the framework as the default rendering methods do? As before, any help with this would be greatly appreciated. Thanks again!

          Kevin

          Show
          Kevin Parkerson added a comment - Hi there, I have yet another question for your team. Thus far we've been using the default gadget rendering methods (shindig.container.createGadget, shindig.container.addGadget, and ashindig.container.renderGadget) in order to utilize the pubsub-2 feature. However, we would like to be able to render gadgets programmatically by generating the url as specified on https://cwiki.apache.org/confluence/display/SHINDIG/iframe+url+format and setting it to the src element of an iframe. We've done this in the past and features such as RPC, tabs, and the old pubsub mechanism worked without problem, but because pubsub-2 changes how the gadgets are rendered it seems they cannot utilize the new pubsub-2 feature. I assume this is the result of not registering the appropriate values with the Shindig/OAA gadget framework. Is there a way to add programmatically created gadgets to the framework as the default rendering methods do? As before, any help with this would be greatly appreciated. Thanks again! Kevin
          Hide
          Javier Pedemonte added a comment -

          @Ilya Shtein, the pubsub-2 makes use of and interacts with a version of the OpenAjax Hub that is written on top of Shindig's RPC code. In order to use TIBCO's OAHub, it would need to be updated so it was based off of the latest version of the OAHub. Then, it should be easy to build a version of Shindig where you have replaced the reference impl of OAHub (in shindig/extras/src/main/javascript/features-extras) with the new TIBCO version.

          Show
          Javier Pedemonte added a comment - @Ilya Shtein, the pubsub-2 makes use of and interacts with a version of the OpenAjax Hub that is written on top of Shindig's RPC code. In order to use TIBCO's OAHub, it would need to be updated so it was based off of the latest version of the OAHub. Then, it should be easy to build a version of Shindig where you have replaced the reference impl of OAHub (in shindig/extras/src/main/javascript/features-extras) with the new TIBCO version.
          Hide
          Javier Pedemonte added a comment -

          @Kevin Parkerson, OpenAjax Hub was implemented such that the code creates and manages the iframe. So what you want to do (create iframe, then set 'src') isn't currently possible with OAHub. I'll keep this in mind going forward, though, and see if there's a good way to add this to OAHub.

          Show
          Javier Pedemonte added a comment - @Kevin Parkerson, OpenAjax Hub was implemented such that the code creates and manages the iframe. So what you want to do (create iframe, then set 'src') isn't currently possible with OAHub. I'll keep this in mind going forward, though, and see if there's a good way to add this to OAHub.
          Hide
          tomer doron added a comment -

          i am having the same issue han mentioned regarding hard coded server base. shouldn't this value come from shindig's container config files (container.js)?

          Show
          tomer doron added a comment - i am having the same issue han mentioned regarding hard coded server base. shouldn't this value come from shindig's container config files (container.js)?
          Hide
          tomer doron added a comment -

          additionally, the fact that the constructor performs a metadata request without the ability fo determine if one is even required seems excessive: in my case (as i am sure in others) i batch the metadata requests prior to generating the gadgets in order to save the extra roundtrips, however, this constructor forces many more metadata requests that are not really required as i can pass the required info (pubsub2?) to shindig.container.createGadget function and save the extra roundtrips.

          Show
          tomer doron added a comment - additionally, the fact that the constructor performs a metadata request without the ability fo determine if one is even required seems excessive: in my case (as i am sure in others) i batch the metadata requests prior to generating the gadgets in order to save the extra roundtrips, however, this constructor forces many more metadata requests that are not really required as i can pass the required info (pubsub2?) to shindig.container.createGadget function and save the extra roundtrips.

            People

            • Assignee:
              Unassigned
              Reporter:
              Han Nguyen
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development