For the basics of the rendering parameters... For the request parameters, are you talking about what is in bullet item 6? http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/Gadget s-API-Specification.html#rfc.section.3.1
The ones we found missing for URL developer consumption, but were already part of Shindig's iframe url, were: view, view-params. We also added one additional parameters for developers: env - to let them know what environment they are running in, e.g. production, sandbox and dev. For our use (not gadget developers use) we need: parent, rpctoken We do security in our own way, since we are integrating to legacy applications. Our security token is very long, so the resultant request must be done by a POST, as the URL exceeds IE's limit of 2000 rather quickly. It is through the security tokens that the developer gets the equivalent of viewer. Plus our tokens are time stamped so caching is not an issue for us. makeRequest documents signing by Oauth, which might be more applicable. For the JS libraries... In order to make use of as much of the JS functions as possible, you need things like hangman substituted messages and preloads. These are very dependent upon what the users specific parameters were, and make Facebook's approach with static JS less desirable. And the "libs" approach of iGoogle require a more stateful server (a problem with a cluster of machines). So once we went with the POST the limit on parameter size was lifted. We put everything needed into a single "is" parameter. It includes <script src=...> tags, it includes the call to gadgets.config, plus a bit more. Plus this parameter is signed to ensure it is not tampered with. Once we did this, large pieces of the core JS API works. The other item is that gadgets core, and rpc use document.location. For obvious things like prefs, but also for rpctoken and parent. This is OK for the very first render, but most URL developers will have multiple pages. For this the "is" parameter includes a "fake url" that can be parsed inside of the gadgets API to get the info, simply replaced document.location with "gadgets_location_href_override || document.location.href;" For a limited JS functionality... If all we want is basic rpc/pubsub, static JS includes would be fine. This may be a good starting point for a standard implementation. The goals would be to ensure security and portability (if possible) Security - at least today, the gadget developer needs to run (and trust) JS code from the gadget server. Portability - can we create a method that will let developers run on multiple sites, hopefully w/o a whitelist of trusted sites? -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Monday, September 28, 2009 12:09 PM To: [email protected] Subject: RE: Reverse proxy and URL gadgets Yes we can work for a common solution to this problem and a standard way to integrate these gadgets.* API features for URL gadgets. For starter we can target pubsub, dynamic height (as we also have found them very much required and we have them implemented in our Shindig code base). Also for #3 if we can have a standard way for forwarding the request paramters to the URL gadgets that will reduce the use of makRequest calls - this as we have seen increases the server round trips. Thanks, Samik ________________________________ From: Weygandt, Jon [mailto:[email protected]] Sent: Mon 9/28/2009 11:44 PM To: [email protected] Subject: RE: Reverse proxy and URL gadgets Regarding #2, parts of the JS features have been implemented for URL gadgets Myspace: http://wiki.developer.myspace.com/index.php?title=Messaging_from_an_IFra me eBay: http://developer.ebay.com/DevZone/selling-manager-applications/Concepts/ SellingManagerApps_APIGuide.html#starting iGoggle: with "limited" support for gadgets.* API, using the libs parameter. I wonder if there are other examples? All of these have different methods for inclusion of the JS, which is a problem for writing portable gadgets. I believe the most important feature to support is RPC and dynamic height. In the future pubsub will also be valuable. Features like makeRequest, and by extension the OpenSocial data requests, are difficult to support due to the same origin policy for XMLHttpRequest. But then, gadget developers choosing to do a URL gadget can use REST and RPC. There's an interesting proposal for OpenSocial, but not for v1.0, regarding this: http://wiki.opensocial.org/index.php?title=Support_iframe_model_applicat ion_in_gadget_spec While we have already solved this, if there is interest, I'd be interested in working for a common solution. Jon -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Monday, September 28, 2009 4:33 AM To: [email protected] Subject: Reverse proxy and URL gadgets Hi, Working with Shindig we have come across some use cases for which we modified shindig code base. 1. For URL gadgets shindig do redirect to the gadget URL, however in the reverse proxy it's an issue for web masters. So we have modified that part to respond as HTTP 200 (no redirect). 2. Why shindig does not support the JS features for URL gadgets? [One reason could be cross site scripting but in *a company setup* with *reverse proxy* this can be useful feature to have] 3. Request parameter passing to all gadgets - We have modified Shindig to pass all the request parameters to the gadgets in a page. We have these features implemented, we love to get an opinion of the community regarding these changes. Thanks, Samik Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
