Shindig
  1. Shindig
  2. SHINDIG-1402

Rendering Open Social gadgets inline (without an IFrame)

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0.0
    • Fix Version/s: 2.5.2
    • Component/s: Java, Javascript , PHP, Website
    • Labels:
      None
    • Environment:
      Should be applicable to any platform Shindig will run

      Description

      Kudos to the team who have come up with such an excellent container and the success we have in many of the open social networking platforms. OpenSocial gadgets IFrame model seems to work great on the web that will let you sandbox all the interactions with the back-end. This is especially very cool to isolate when you don't have control on each of the gadget sources.

      Background:
      Moving to the enterprise space brings in extra challenges. One such request we are seeing is rendering open social gadgets inline. This seems an important feature for many situations where gadgets are trusted and scalability is a concern. Isolating gadgets with each gadget loading its own resources may not be required. I am sure there may be some tricks to workaround. But from clean programming model perspective, we would like to propose this feature.

      Here are some of the concerns expressed for which we were attempting to prototype rendering gadgets inline:

      • Load common JavaScript libraries globally
      • Load Gadget features globally
      • Address some of the memory leak issues with iframes
      • Reduce the download size of the page
      • Reduce number of requests to server
      • Avoid iframe reloading when the gadgets are moved on the page

      Feature Request:
      Support Inline container in addition to IFrame container. There could be an API to render gadgets inline vs iframe. There are more observations in terms of namespace conflicts, duplicate JavaScript, and CSS loading, duplicate feature loading etc. We have a working patch on 2.0.0, but before we go too far with the implementation, I wanted get the thoughts from the community and see what you think about adding this feature to Shindig.

      Thanks in advance for the feedback.

      1. patch_20100921.patch
        231 kB
        Kris Vishwanathan
      2. inline-initial-port.patch
        522 kB
        Michael Beaver
      3. inlineFeature.txt
        52 kB
        Andy Smith
      4. inline.patch
        103 kB
        Michael Beaver
      5. inline_feature_patch_20101103.patch
        24 kB
        Kai Feng Zhang
      6. inline_20100824.patch
        491 kB
        Kris Vishwanathan

        Activity

        Hide
        Jonathan Beri added a comment -

        This is great. I'd really like to see this working with Caja. It seems like it would be easier to integrate the Cajita Runtime with global library (see link: http://code.google.com/p/google-caja/wiki/HostingModules.) There's a nice demo of multiple Cajoled widgets running without IFrames: http://caja-corkboard.appspot.com/.

        From my understanding, Caja might actually simplify creating Global libraries through it an "introduction service." However, I realize some implementers may not want to use Caja.

        Show
        Jonathan Beri added a comment - This is great. I'd really like to see this working with Caja. It seems like it would be easier to integrate the Cajita Runtime with global library (see link: http://code.google.com/p/google-caja/wiki/HostingModules .) There's a nice demo of multiple Cajoled widgets running without IFrames: http://caja-corkboard.appspot.com/ . From my understanding, Caja might actually simplify creating Global libraries through it an "introduction service." However, I realize some implementers may not want to use Caja.
        Hide
        Mark Weitzel added a comment -

        Jonathan,

        One question for you.... We make heavy use of Dojo, and it's my understanding that Caja and Dojo don't always play nice together. I think that's one reason we are exploring the idea of having a "Caja-less" implementation. Do you have any thoughts/ideas of how we can confirm this? I believe the problem was with Dojo's use of eval....

        Thanks!

        Show
        Mark Weitzel added a comment - Jonathan, One question for you.... We make heavy use of Dojo, and it's my understanding that Caja and Dojo don't always play nice together. I think that's one reason we are exploring the idea of having a "Caja-less" implementation. Do you have any thoughts/ideas of how we can confirm this? I believe the problem was with Dojo's use of eval.... Thanks!
        Hide
        Kris Vishwanathan added a comment -

        My understanding of Caja is more of a JavaScript scrubbing to prevent malware. Some of the security concerns such as phishing, cross-site scripting are best addressed using Caja. The Caja's virtual iframe concept is about rewriting your JavaScript to remove security risks. I am no expert on Caja but I think the purpose is to sandbox gadgets addressing client side security concerns, further if you have a complex code that makes it difficult to debug

        Inlining feature on the other end is all about trusted code, users don't want to take a hit on loading duplicate resources in every iframe, same gadget that works in iframe should work on a page without iframes.

        So the way we are thinking is to have simple api call similar to shindig.container.renderGadget there will be shindig.container.renderGadgetInline, then load the gadget html using Ajax into page DOM, instead of iFrame src reference. There are other issues that we need to resolve with this approach and we are currently working on them.

        Show
        Kris Vishwanathan added a comment - My understanding of Caja is more of a JavaScript scrubbing to prevent malware. Some of the security concerns such as phishing, cross-site scripting are best addressed using Caja. The Caja's virtual iframe concept is about rewriting your JavaScript to remove security risks. I am no expert on Caja but I think the purpose is to sandbox gadgets addressing client side security concerns, further if you have a complex code that makes it difficult to debug Inlining feature on the other end is all about trusted code, users don't want to take a hit on loading duplicate resources in every iframe, same gadget that works in iframe should work on a page without iframes. So the way we are thinking is to have simple api call similar to shindig.container.renderGadget there will be shindig.container.renderGadgetInline, then load the gadget html using Ajax into page DOM, instead of iFrame src reference. There are other issues that we need to resolve with this approach and we are currently working on them.
        Hide
        Jonathan Beri added a comment -

        @Mark Yes, Caja doesn't allow EVAL. However, that pertains to the "Cajoled" code itself. I'm not sure if/how it will affect the container code. What I'm thinking is that the Caja JavaScript runtime would run as part of the container. It would be up to the gadget developer to worry about including EVAL into their code.

        Here's a discussion on debugging Shinding with Caja in IFrame: http://code.google.com/p/google-caja/wiki/DebuggingShindig
        And another about using JavaScript libraries in Caja: http://code.google.com/p/google-caja/wiki/OpenProblems

        @Kris Your summary is correct, Caja addresses client-side security. In short, it compiles code and then needs the Caja JavaScript runtime. Inline + Caja would allow semi-trusted or even untrusted code without the downside of IFrames that you mentioned.

        I'd propose a third API, something like shindig.container.renderCajaGadgetInline. It might make the most sense to implement Inline Gadgets support and see how we can make Caja work (instead of trying to develop both simultaneously.)

        I'll reach out to the Caja folks and see if they can chime in about the Dojo/Eval issue.

        Show
        Jonathan Beri added a comment - @Mark Yes, Caja doesn't allow EVAL. However, that pertains to the "Cajoled" code itself. I'm not sure if/how it will affect the container code. What I'm thinking is that the Caja JavaScript runtime would run as part of the container. It would be up to the gadget developer to worry about including EVAL into their code. Here's a discussion on debugging Shinding with Caja in IFrame: http://code.google.com/p/google-caja/wiki/DebuggingShindig And another about using JavaScript libraries in Caja: http://code.google.com/p/google-caja/wiki/OpenProblems @Kris Your summary is correct, Caja addresses client-side security. In short, it compiles code and then needs the Caja JavaScript runtime. Inline + Caja would allow semi-trusted or even untrusted code without the downside of IFrames that you mentioned. I'd propose a third API, something like shindig.container.renderCajaGadgetInline. It might make the most sense to implement Inline Gadgets support and see how we can make Caja work (instead of trying to develop both simultaneously.) I'll reach out to the Caja folks and see if they can chime in about the Dojo/Eval issue.
        Hide
        Kris Vishwanathan added a comment -

        Here are some of the functions that are supported in the patch. Patch is created from Shindig trunk snapshot taken on 08/24/2010

        • Inline gadget functionality
        • API support to render gadget inline (shindig.gadget.createInlineGadget(..))
        • Sample working Horoscope gadget with sample html to render
        • SampleContainer changes to switch between iframe vs inline
        • SocialHelloWorld and SocialActivitiesWorld working samples
        • Dynamic height working sample
        • Namespace specific to inline gadgets fix
        • user preferences fix for inline gadget
        • Couple of other fixes related to inline
        Show
        Kris Vishwanathan added a comment - Here are some of the functions that are supported in the patch. Patch is created from Shindig trunk snapshot taken on 08/24/2010 Inline gadget functionality API support to render gadget inline (shindig.gadget.createInlineGadget(..)) Sample working Horoscope gadget with sample html to render SampleContainer changes to switch between iframe vs inline SocialHelloWorld and SocialActivitiesWorld working samples Dynamic height working sample Namespace specific to inline gadgets fix user preferences fix for inline gadget Couple of other fixes related to inline
        Hide
        Kris Vishwanathan added a comment -

        Here is the codereview request url: http://codereview.appspot.com/1986047/

        Show
        Kris Vishwanathan added a comment - Here is the codereview request url: http://codereview.appspot.com/1986047/
        Hide
        Jasvir Nagra added a comment -

        Sorry I missed this CL earlier. Yes Caja does not support "eval" the compiler is a serverside component and we don't know what the arguments to eval() are at compile time. To the extent that dojo uses eval (and other means of creating code dynamically fr'instance using Function constructor, document.createElement('script' | 'iframe'), programs that use dojo won't work cajoled. The input language is converging on code written in ES5-strict and to the extent that libraries support ES5-strict, they will work with Caja.

        I love the work being done to allow inlining.

        With the current implementation, what is the effect of inlining a gadget that requests cajoling? For example, http://www.thinkfu.com/trivial-caja.xml

        Given that you expect this api to be used only in cases where the gadget is trusted, can you modify the api to make that explicit that the container author is making themselves vulnerable to gadgets they inline via this API. Gadgets included in this fashion have access to cookies, xss errors in them affect secrets held in the container as well as in other gadgets on the page etc. I suggest shindig.gadget.createUnprotectedInlineGadget.

        Show
        Jasvir Nagra added a comment - Sorry I missed this CL earlier. Yes Caja does not support "eval" the compiler is a serverside component and we don't know what the arguments to eval() are at compile time. To the extent that dojo uses eval (and other means of creating code dynamically fr'instance using Function constructor, document.createElement('script' | 'iframe'), programs that use dojo won't work cajoled. The input language is converging on code written in ES5-strict and to the extent that libraries support ES5-strict, they will work with Caja. I love the work being done to allow inlining. With the current implementation, what is the effect of inlining a gadget that requests cajoling? For example, http://www.thinkfu.com/trivial-caja.xml Given that you expect this api to be used only in cases where the gadget is trusted, can you modify the api to make that explicit that the container author is making themselves vulnerable to gadgets they inline via this API. Gadgets included in this fashion have access to cookies, xss errors in them affect secrets held in the container as well as in other gadgets on the page etc. I suggest shindig.gadget.createUnprotectedInlineGadget.
        Hide
        Kris Vishwanathan added a comment -

        I am thinking we should have caja working for inline gadgets the same way it does for iframe. The choice is up to the users. If they are concerned about security they can use caja in conjunction with inline. So part of next steps, we are making sure all the gadgets, social API works then get caja working as well.

        Show
        Kris Vishwanathan added a comment - I am thinking we should have caja working for inline gadgets the same way it does for iframe. The choice is up to the users. If they are concerned about security they can use caja in conjunction with inline. So part of next steps, we are making sure all the gadgets, social API works then get caja working as well.
        Hide
        Kris Vishwanathan added a comment -

        Here is the updated patch, based on the feedback from Paul Linder. Please do review and let us know if its good to go into the trunk. Once you apply the patch, you will notice sampleconainer.html will have one more checkbox for toggling inline option. You can test HelloSocialWorld.xml and HelloActivitiesWorld working inline.

        Show
        Kris Vishwanathan added a comment - Here is the updated patch, based on the feedback from Paul Linder. Please do review and let us know if its good to go into the trunk. Once you apply the patch, you will notice sampleconainer.html will have one more checkbox for toggling inline option. You can test HelloSocialWorld.xml and HelloActivitiesWorld working inline.
        Hide
        Andy Smith added a comment -

        Kris,

        I started digging through some of the changes in the shindig-container. One thing that I think would help out here is to refactor the inlining code into its own feature limiting core container changes as much as possible , I started to do some of this yesterday and although there is an issue with the metadata request, this should give you an idea of how you can start to structure the changes.

        Show
        Andy Smith added a comment - Kris, I started digging through some of the changes in the shindig-container. One thing that I think would help out here is to refactor the inlining code into its own feature limiting core container changes as much as possible , I started to do some of this yesterday and although there is an issue with the metadata request, this should give you an idea of how you can start to structure the changes.
        Hide
        Andy Smith added a comment -

        Kris,

        I have not had a chance to look into the server side code yet, but for the container changes, I think it makes sense to move inlining to its own feature in extras. I've attached a patch where I started to do some of that. This current patch has an error related to the get metadata request for inlined gadgets which I have not had a chance to track down yet, but should give you a start on refactoring.

        Show
        Andy Smith added a comment - Kris, I have not had a chance to look into the server side code yet, but for the container changes, I think it makes sense to move inlining to its own feature in extras. I've attached a patch where I started to do some of that. This current patch has an error related to the get metadata request for inlined gadgets which I have not had a chance to track down yet, but should give you a start on refactoring.
        Hide
        Scott Plumlee added a comment - - edited

        This is a great addition and I'm trying to verify what features work with it (looking to test RPC and pubsub2). One issue I have noticed is that the generated script element is escaped, resulting in a script src attribute such as 'http://localhost:8080/gadgets/js/core:rpc.js?container=default&nocache=1&debug=1&c=0'. Shindig doesn't honor the escaped ampersands, so it doesn't seem possible to get a unminified version of the javascript that's inserted into the head element.

        One more question if I may - requiring pubsub-2 in a gadget rendered inline causes the gadget to fail rendering silently. I'm trying to verify exactly where the issue lies, but it seems that the patch should be able to handle OAA inline gadgets as there are test cases for the type of gadget. I'm using sample8 as a test, adding a required feature of pubsub-2, but it fails w/o rendering the inline gadget.

        Show
        Scott Plumlee added a comment - - edited This is a great addition and I'm trying to verify what features work with it (looking to test RPC and pubsub2). One issue I have noticed is that the generated script element is escaped, resulting in a script src attribute such as 'http://localhost:8080/gadgets/js/core:rpc.js?container=default&nocache=1&debug=1&c=0'. Shindig doesn't honor the escaped ampersands, so it doesn't seem possible to get a unminified version of the javascript that's inserted into the head element. One more question if I may - requiring pubsub-2 in a gadget rendered inline causes the gadget to fail rendering silently. I'm trying to verify exactly where the issue lies, but it seems that the patch should be able to handle OAA inline gadgets as there are test cases for the type of gadget. I'm using sample8 as a test, adding a required feature of pubsub-2, but it fails w/o rendering the inline gadget.
        Hide
        Kris Vishwanathan added a comment -

        Hi Scott, We had this working earlier,seems things are constantly changing on the trunk its been a challenge for us to keep up. We are trying to refactor a bit and make available as a feature. I will update another patch with pubsub2 function.

        Show
        Kris Vishwanathan added a comment - Hi Scott, We had this working earlier,seems things are constantly changing on the trunk its been a challenge for us to keep up. We are trying to refactor a bit and make available as a feature. I will update another patch with pubsub2 function.
        Hide
        Scott Plumlee added a comment -

        Hi Kris. That would be great - I'm trying the patch file against the latest trunk just to see if that works.

        Show
        Scott Plumlee added a comment - Hi Kris. That would be great - I'm trying the patch file against the latest trunk just to see if that works.
        Hide
        Scott Plumlee added a comment -

        The patch file has three locations where it replaces ampersands with '&', which causes the errors in parsing the GET arguments by shindig (doesn't respect the debug=1'. If you remove those changes, the URL is correctly rendered, at the cost of properly escaping the ampersands, of course. File being patched starts at line 4605, it's [SOURCECODE]/java/gadgets/src/main/java/org/apache/shindig/gadgets/render/RenderingGadgetRewriter.java

        Then you can pass in debug: true in your gadget object and get unminified js files.

        Show
        Scott Plumlee added a comment - The patch file has three locations where it replaces ampersands with '&', which causes the errors in parsing the GET arguments by shindig (doesn't respect the debug=1'. If you remove those changes, the URL is correctly rendered, at the cost of properly escaping the ampersands, of course. File being patched starts at line 4605, it's [SOURCECODE] /java/gadgets/src/main/java/org/apache/shindig/gadgets/render/RenderingGadgetRewriter.java Then you can pass in debug: true in your gadget object and get unminified js files.
        Hide
        Kevin Parkerson added a comment -

        Hi there, awesome work with the inline feature. One thing I'm curious about is accessing _MODULE_ID_ from a feature. I notice that when placed inside the CDATA this value is replaced with an integer representing the module ID of the gadget, but the inline feature scripts are placed before gadgets.config.init(..) and _MODULE_ID_ is thus undefined. Is there a way of obtaining the module ID of the gadget from the script of a feature when required on an inline gadget?

        Show
        Kevin Parkerson added a comment - Hi there, awesome work with the inline feature. One thing I'm curious about is accessing _ MODULE_ID _ from a feature. I notice that when placed inside the CDATA this value is replaced with an integer representing the module ID of the gadget, but the inline feature scripts are placed before gadgets.config.init(..) and _ MODULE_ID _ is thus undefined. Is there a way of obtaining the module ID of the gadget from the script of a feature when required on an inline gadget?
        Hide
        Mat Mannion added a comment -

        You should be able to get the Module ID using:

        new gadgets.Prefs().getModuleId();

        Show
        Mat Mannion added a comment - You should be able to get the Module ID using: new gadgets.Prefs().getModuleId();
        Hide
        Kevin Parkerson added a comment -

        @Mat

        Thanks for the quick response. That works just fine for iframe gadgets, but for inline gadgets it returns "undefined", at least on my build. Has anyone used new gadgets.Prefs().getModuleId(); in a feature included as part of an inline gadget successfully?

        Show
        Kevin Parkerson added a comment - @Mat Thanks for the quick response. That works just fine for iframe gadgets, but for inline gadgets it returns "undefined", at least on my build. Has anyone used new gadgets.Prefs().getModuleId(); in a feature included as part of an inline gadget successfully?
        Hide
        Scott Plumlee added a comment -

        Hello again. A lead dev on our team noticed another issue with inline gadets - link tags inside inline gadget CDATA blocks are not injected into the HEAD of the document. It just silently fails to write the link element. Seems to be something in the parsing of the URL for the proxied content, but not sure. We will try to look a bit more and see if we can offer a patch.

        Show
        Scott Plumlee added a comment - Hello again. A lead dev on our team noticed another issue with inline gadets - link tags inside inline gadget CDATA blocks are not injected into the HEAD of the document. It just silently fails to write the link element. Seems to be something in the parsing of the URL for the proxied content, but not sure. We will try to look a bit more and see if we can offer a patch.
        Hide
        Kai Feng Zhang added a comment - - edited

        We originally posted inlining work directly into the existing container shindig-container/server side components...

        After reviewing some of these changes and learning more about the features, we've stepped back and refactored those changes as a feature on the common container. I add this new patch, which is based on new common container and its new patch: https://issues.apache.org/jira/browse/SHINDIG-1460

        After apply the patch, access http://localhost:8080/container/helloworld_common3.html you would see the inline gadget and iframe gadget being rendered on same page, though they are helloworld gadgets.

        Show
        Kai Feng Zhang added a comment - - edited We originally posted inlining work directly into the existing container shindig-container/server side components... After reviewing some of these changes and learning more about the features, we've stepped back and refactored those changes as a feature on the common container. I add this new patch, which is based on new common container and its new patch: https://issues.apache.org/jira/browse/SHINDIG-1460 After apply the patch, access http://localhost:8080/container/helloworld_common3.html you would see the inline gadget and iframe gadget being rendered on same page, though they are helloworld gadgets.
        Hide
        Kai Feng Zhang added a comment -

        The first problem inline gadget rendering needs to solve is about namespacing conflict.

        Since some gadget declare a unique identifier for some element in dom, such as <div id="hello">, if this gadget is rendered with inline multiple times on same page, it's a problem of element id conflict.

        As our former implementation(in original patch to support inline) is based on the iWidget context concept and request the gadget developer to rewrite their gadget with a scope, which will generate a unique identifier for each element in inline gadget, to avoid namespacing conflict issue.

        It might be a little reluctant for gadget developer to accept and it also needs effort to rewrite thousands of existing gadgets. So we did not enable this implementation in our new inline patch. https://issues.apache.org/jira/browse/SHINDIG-1402

        But currently seems we didn't find a better way to solve it. So could someone please review and propose any better way to do solve this namespacing problem?

        Show
        Kai Feng Zhang added a comment - The first problem inline gadget rendering needs to solve is about namespacing conflict. Since some gadget declare a unique identifier for some element in dom, such as <div id="hello">, if this gadget is rendered with inline multiple times on same page, it's a problem of element id conflict. As our former implementation(in original patch to support inline) is based on the iWidget context concept and request the gadget developer to rewrite their gadget with a scope, which will generate a unique identifier for each element in inline gadget, to avoid namespacing conflict issue. It might be a little reluctant for gadget developer to accept and it also needs effort to rewrite thousands of existing gadgets. So we did not enable this implementation in our new inline patch. https://issues.apache.org/jira/browse/SHINDIG-1402 But currently seems we didn't find a better way to solve it. So could someone please review and propose any better way to do solve this namespacing problem?
        Hide
        wangdaw added a comment -

        The inline feature impacts some shindig API. shindig.auth feature does not work for inline rendering
        1. shindig.auth feature depends on gadgets.util.getUrlParameters, which relays on page's url. In iframe rendering model, it is the gadget's xml->html servlet url. For inline rendering model, it is container page's url. the authToken could NOT be retrieved correctly.
        2. shindig.auth is a object of class shindig.Auth; it is a global object for one gadget instance in its iframe. For inline rendering model, all
        shindig.auth object for each gadget are in one DOM scope. As a result, all gadget instances are using the same shindig.auth object .
        3. For this kind of issue, we need to isolate gadget instance related variable and API.
        3.1. inject authToken to shindig.auth object correctly for each gadget instance
        3.2. each gadget use shindig.auth api under gadget instance scope to retrieve/update its authToken

        Show
        wangdaw added a comment - The inline feature impacts some shindig API. shindig.auth feature does not work for inline rendering 1. shindig.auth feature depends on gadgets.util.getUrlParameters, which relays on page's url. In iframe rendering model, it is the gadget's xml->html servlet url. For inline rendering model, it is container page's url. the authToken could NOT be retrieved correctly. 2. shindig.auth is a object of class shindig.Auth; it is a global object for one gadget instance in its iframe. For inline rendering model, all shindig.auth object for each gadget are in one DOM scope. As a result, all gadget instances are using the same shindig.auth object . 3. For this kind of issue, we need to isolate gadget instance related variable and API. 3.1. inject authToken to shindig.auth object correctly for each gadget instance 3.2. each gadget use shindig.auth api under gadget instance scope to retrieve/update its authToken
        Hide
        Kai Feng Zhang added a comment -

        Submit patch for code review here: http://codereview.appspot.com/2927041/

        Show
        Kai Feng Zhang added a comment - Submit patch for code review here: http://codereview.appspot.com/2927041/
        Hide
        Hasan Ceylan added a comment -

        Hello,

        We are also interested in having an "inline way of rendering" gadgets.

        What is the status / progress on this issue? I see that code a patch has been submitted for review but it has been some time since the last time this issue was touched.

        Best regards,
        Hasan Ceylan

        Show
        Hasan Ceylan added a comment - Hello, We are also interested in having an "inline way of rendering" gadgets. What is the status / progress on this issue? I see that code a patch has been submitted for review but it has been some time since the last time this issue was touched. Best regards, Hasan Ceylan
        Hide
        Eric Grande added a comment -

        Hello,

        Are there any plans to get this implemented. We are using Shindig heavily in the enterprise and many developers have asked for an inline rendering option. Does the patch work or is it written against too old of a Shindig version?

        -Eric

        Show
        Eric Grande added a comment - Hello, Are there any plans to get this implemented. We are using Shindig heavily in the enterprise and many developers have asked for an inline rendering option. Does the patch work or is it written against too old of a Shindig version? -Eric
        Hide
        Michael Beaver added a comment -

        Hi, Eric.

        We are still actively reworking this patch based on shindig 3.0. Quite a lot has changed from the original 2.0.2-based patch and we hope to have a version of the patch that is in an acceptable state for community review soon. Our apologies for the lack of external activity and communication on this work, but we do appreciate the interest from you and the community in our work. Stay tuned and hopefully we'll have something for you shortly.

        Thanks!

        Show
        Michael Beaver added a comment - Hi, Eric. We are still actively reworking this patch based on shindig 3.0. Quite a lot has changed from the original 2.0.2-based patch and we hope to have a version of the patch that is in an acceptable state for community review soon. Our apologies for the lack of external activity and communication on this work, but we do appreciate the interest from you and the community in our work. Stay tuned and hopefully we'll have something for you shortly. Thanks!
        Hide
        Eric Grande added a comment -

        Hi Mike,

        This is great news. Please let me know if myself and team can start testing for you. We are willing to help out with the implementation as well if you need more resources. Can you comment on how you are going to help protect from Javascript collisions and address security issues, ie. Caja? The iframe option only is becoming a real adoption road block for us and having another option to render in div would be HUGE!

        -Eric

        Show
        Eric Grande added a comment - Hi Mike, This is great news. Please let me know if myself and team can start testing for you. We are willing to help out with the implementation as well if you need more resources. Can you comment on how you are going to help protect from Javascript collisions and address security issues, ie. Caja? The iframe option only is becoming a real adoption road block for us and having another option to render in div would be HUGE! -Eric
        Hide
        Michael Beaver added a comment - - edited

        This patch (initial-inline-port.patch) is the initial stab at porting the 2.0.2 patch to the 3.0 codebase. We're no longer using this version due to collisions with other features we experienced (like open-views), but it does contain all the modifications to rpc/osapi/prefs/etc. This should be used as a reference for the types of things that will need to be addressed in the mixin approach.

        Show
        Michael Beaver added a comment - - edited This patch (initial-inline-port.patch) is the initial stab at porting the 2.0.2 patch to the 3.0 codebase. We're no longer using this version due to collisions with other features we experienced (like open-views), but it does contain all the modifications to rpc/osapi/prefs/etc. This should be used as a reference for the types of things that will need to be addressed in the mixin approach.
        Hide
        Michael Beaver added a comment - - edited

        This file (inline.patch) is the mixin version of the inline patch. It's not complete and we currently see issues with rpc/osapi/prefs. It is much less invasive to the core of shindig though and the goal is to contain as much as possible within the inline namespace of the container.

        Show
        Michael Beaver added a comment - - edited This file (inline.patch) is the mixin version of the inline patch. It's not complete and we currently see issues with rpc/osapi/prefs. It is much less invasive to the core of shindig though and the goal is to contain as much as possible within the inline namespace of the container.
        Hide
        Michael Beaver added a comment -

        Eric, btw I forgot to mention it earlier, we would love to have you help out with the implementation as resources are slim at the moment. The Caja model is definitely of interest to us for avoiding collisions and addressing security, and any thoughts you have on the matter are more than welcome.

        Show
        Michael Beaver added a comment - Eric, btw I forgot to mention it earlier, we would love to have you help out with the implementation as resources are slim at the moment. The Caja model is definitely of interest to us for avoiding collisions and addressing security, and any thoughts you have on the matter are more than welcome.
        Hide
        Richard Kettelerij added a comment -
        Show
        Richard Kettelerij added a comment - Any news on this issue? Is this effort related to http://docs.opensocial.org/display/OSD/Investigate+spec+changes+to+support+inline+gadgets?
        Hide
        Ryan Baxter added a comment -

        Can we close this? I don't know if anyone is pushing this forward anymore.

        Show
        Ryan Baxter added a comment - Can we close this? I don't know if anyone is pushing this forward anymore.
        Hide
        Matt Franklin added a comment -

        Personally, I would really like to see this work continue. I think an inline option for gadgets is important for the future of any OpenSocial based application. We hope to take this on at some point this year starting from the patch provided by Michael

        Show
        Matt Franklin added a comment - Personally, I would really like to see this work continue. I think an inline option for gadgets is important for the future of any OpenSocial based application. We hope to take this on at some point this year starting from the patch provided by Michael
        Hide
        Ryan Baxter added a comment -

        Matt Franklin we no longer have a need for this at IBM. What are your use cases?

        Show
        Ryan Baxter added a comment - Matt Franklin we no longer have a need for this at IBM. What are your use cases?
        Hide
        Matt Franklin added a comment -

        We are starting to see Rave & OpenSocial be used as a modular application development strategy for smaller, targeted apps where the need for low gadget load time outweighs the benefits of the iFrame.

        Show
        Matt Franklin added a comment - We are starting to see Rave & OpenSocial be used as a modular application development strategy for smaller, targeted apps where the need for low gadget load time outweighs the benefits of the iFrame.
        Hide
        Atul Kshirsagar added a comment -

        Any update on this issue? For the same reasons mentioned by Matt Franklin we are hoping that this feature will be added.

        Show
        Atul Kshirsagar added a comment - Any update on this issue? For the same reasons mentioned by Matt Franklin we are hoping that this feature will be added.
        Hide
        Chris Spiliotopoulos added a comment - - edited

        I give +1 vote on this one - in my opinion this is one of the most important issues that makes integrators invent various hacks/workarounds on how to get gadgets on a page load faster providing a seamless UX and maybe the most common pain point that drives others away from OpenSocial & gadget development.

        I'm a strong believer and evangelist of the gadget development (pluggable) model and I can tell you for sure that it's a hard road to convincing people about the benefits of fully decoupled software development as I always get questions regarding iframes and how difficult it is to make them behave well on a single page. At the moment we've reached a point where we can build real-time and responsive dashboard gadget apps but it took time and effort and a custom layer for orchestrating components - through events mostly.

        Just a few hours ago I came across a presentation for Advanced OpenSocial dev and the author stated boldly:

        Never, never, never use document.write() calls or bypass the CSS/JS injection mechanism of the container.

        Well, I don't agree - at all. You have to do whatever it takes to provide a great UX so this type of statements just come to show the weak points that need to be revisited. And as Matt Franklin stated. if OpenSocial wants a future it needs to be up-to-date.

        Show
        Chris Spiliotopoulos added a comment - - edited I give +1 vote on this one - in my opinion this is one of the most important issues that makes integrators invent various hacks/workarounds on how to get gadgets on a page load faster providing a seamless UX and maybe the most common pain point that drives others away from OpenSocial & gadget development. I'm a strong believer and evangelist of the gadget development (pluggable) model and I can tell you for sure that it's a hard road to convincing people about the benefits of fully decoupled software development as I always get questions regarding iframes and how difficult it is to make them behave well on a single page. At the moment we've reached a point where we can build real-time and responsive dashboard gadget apps but it took time and effort and a custom layer for orchestrating components - through events mostly. Just a few hours ago I came across a presentation for Advanced OpenSocial dev and the author stated boldly: Never, never, never use document.write() calls or bypass the CSS/JS injection mechanism of the container. Well, I don't agree - at all. You have to do whatever it takes to provide a great UX so this type of statements just come to show the weak points that need to be revisited. And as Matt Franklin stated. if OpenSocial wants a future it needs to be up-to-date.
        Hide
        Ryan Baxter added a comment -

        Both models need to be supported. We can look at this for 3.0, does anyone want to step up and drive this?

        Show
        Ryan Baxter added a comment - Both models need to be supported. We can look at this for 3.0, does anyone want to step up and drive this?
        Hide
        Chris Spiliotopoulos added a comment -

        Ryan Baxter I'd be happy to give a helping hand for anything required [code/test/design/docs] as long as someone from the core team provides some guidelines. The patch submitted by Kris Vishwanathan is outdated and doesn't work with current version of the code.

        Show
        Chris Spiliotopoulos added a comment - Ryan Baxter I'd be happy to give a helping hand for anything required [code/test/design/docs] as long as someone from the core team provides some guidelines. The patch submitted by Kris Vishwanathan is outdated and doesn't work with current version of the code.
        Hide
        Ryan Baxter added a comment -

        Chris Spiliotopoulos thanks for stepping up. I am sure all of the committers would be willing to help along the way.

        Show
        Ryan Baxter added a comment - Chris Spiliotopoulos thanks for stepping up. I am sure all of the committers would be willing to help along the way.
        Hide
        Chris Spiliotopoulos added a comment -

        Ryan Baxter no prob. I'll start by getting a git clone of the repository and apply Kris Vishwanathan patch to see if I can make it work. Could you walk me through the commit process you currently follow? Send me an email if you wish.

        Show
        Chris Spiliotopoulos added a comment - Ryan Baxter no prob. I'll start by getting a git clone of the repository and apply Kris Vishwanathan patch to see if I can make it work. Could you walk me through the commit process you currently follow? Send me an email if you wish.
        Hide
        Ryan Baxter added a comment -

        See the Creating and submitting patch section here http://shindig.apache.org/community_overview.html

        Show
        Ryan Baxter added a comment - See the Creating and submitting patch section here http://shindig.apache.org/community_overview.html
        Hide
        Chris Spiliotopoulos added a comment -

        Ryan Baxter Thanks - already done. So, any patches should be submitted only through Subversion? I intended to clone the GitHub master repo and trigger pull requests from there.

        Show
        Chris Spiliotopoulos added a comment - Ryan Baxter Thanks - already done. So, any patches should be submitted only through Subversion? I intended to clone the GitHub master repo and trigger pull requests from there.
        Hide
        Ryan Baxter added a comment -

        There is no way for us to merge the pull request in from GitHub. Apache doesn't allow us to do that. You must submit a patch through subversion.

        Show
        Ryan Baxter added a comment - There is no way for us to merge the pull request in from GitHub. Apache doesn't allow us to do that. You must submit a patch through subversion.
        Hide
        Chris Spiliotopoulos added a comment -

        Ryan Baxter Ok, got it. Thanks. I'll be in touch.

        Show
        Chris Spiliotopoulos added a comment - Ryan Baxter Ok, got it. Thanks. I'll be in touch.

          People

          • Assignee:
            Unassigned
            Reporter:
            Kris Vishwanathan
          • Votes:
            6 Vote for this issue
            Watchers:
            18 Start watching this issue

            Dates

            • Created:
              Updated:

              Time Tracking

              Estimated:
              Original Estimate - 672h
              672h
              Remaining:
              Remaining Estimate - 672h
              672h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development