The concept of having a framework (e.g. OpenSocial Gadgets) that allows developers to embed a custom application into a page, whether HTML gadget or URL "thing" is very valuable. The URL "thing" should interact with the page the way HTML gadgets do, but the style of application development is very different.
I'm open to Randy's comments on what to call them, or how to position them for the community. Somewhere I remember Google's initial position on URL gadgets as a way to quickly port an existing application into the gadget framework. Just to correct a few things from the specifics of Java API: - RPC should be able to work both ways, ifpc with RpcRelay file is one pain, but ifpc is fading away. Not to mention that 2-way rpc may be little used till pubsub comes back in its full glory and by that time ifpc will not be an issue. - up_xxx should work fine. But unlike HTML gadgets using Prefs(), URL gadgets simply get the query parameters server side. - view parameters (from requestNavigateTo()), well that's not part of the OpenSocial specification - but a spec update is all that's needed. - Yes, makeRequest, templating, pipelining, preloading, etc... All don't work, but that's the "very different" style of development that URL gadget authors face. - Remember all OpenSocial data is available via REST and RPC calls. - Feature parameters - not sure where Shindig uses that? - Container config - another issue - that will be handled by the new RenderContext==URLGADGET, and the JsServlet will generate the proper code. This is the equivalent of the RenderingGadgetRewriter inject methods. This is one of the areas where there are issues, and my thoughts are that we inject only what is invariant wrt user parameters. -----Original Message----- From: Randy Hudson [mailto:[email protected]] Sent: Wednesday, December 02, 2009 9:02 AM To: [email protected] Subject: RE: Next step towards URL gadgets - design proposal Are URL "gadgets" even gadgets? They seem to have the following gaps/limitations: - Even though they are given a URL from which to fetch javascript, most of the javascript won't function - RPC only works in one direction (?) - makeRequest, proxying, appdata, etc. are all broken - Templating and markup aren't supported - Data pipelining isn't supported - Preloading resources isn't supported - Providing userprefs or messages as URL params doesn't really work - View parameters, Feature parameters aren't available I find it confusing that these "embedded pages" are called gadgets, when often they are little more than a bookmark to some external site (like twitter), typically having little interaction with the site in which they appear. I like Jon's suggestion of scoping URL gadgets to some very small API (perhaps just being able to update the "chrome", requesting to be maximized, etc.). Maybe it would help to start calling these things something other than Gadgets? Otherwise, there's this subliminal force telling us to provide two different ways of doing everything, often when one way is enough (e.g. Jon's reference to message bundles). --Randy Hudson From: "Weygandt, Jon" <[email protected]> To: <[email protected]> Date: 12/01/2009 11:31 AM Subject: RE: Next step towards URL gadgets - design proposal Just so that it is known, more on the design: I'm taking liberty in defining "URL gadget JS API" based on: *) Shindig does not support anything today. *) Very few actual server implementations for URL gadgets exist *) Our experience with URL gadgets. Our implementation has quite a few URL gadgets, but the implementation is propriety *) You cannot support cross domain XMLHttpRequests - no makeRequest etc... Just to go a bit further... Just about every URL gadget author will have a multi-page URL gadget. That is one which the location URL changes over time. That's just the typical pattern for these type of applications. We must make the interface work for them, and be relatively easy for them to implement. I believe that full API support using libs, would require either: *) A really long lib URL *) Maintenance of session state on the server *) A complex calling procedure None of the above are really good. But if we narrow down the scope of the API to simply what cannot be replaced by typical URL server side code, it then becomes easier. For an example, think about how one would do message bundles Prefs.getMsg? (These need user prefs for hangman substitution) Then think, does a URL gadget developer even need this? (They don't, I18N is done differently for URL apps) Jon -----Original Message----- From: Weygandt, Jon [mailto:[email protected]] Sent: Tuesday, December 01, 2009 8:14 AM To: [email protected] Subject: RE: Next step towards URL gadgets - design proposal The URL to the gadget developers server will have up_xxx parameters for them to access the parameters. As to "setprefs", these are done through rpc. Rpc will be supported, just like it is today - that is there will be an rpctoken on the URL (presumably the fragment portion). This rpctoken is used to validate themselves to the container. Handling of the rpctoken, and initial processing of the rpc call, is container side JS - independent of HTML or URL gadgets. Ultimate handling of the setpref service call is that of the container, which is NOT anything Shindig code is responsible for. I predict the JS code inside of the URL gadget (that which comes from the "libs" parameter) will be very similar to existing code. Generally I will remove calls that are not within the narrow specification for "URL gadget JS API". -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Tuesday, December 01, 2009 8:03 AM To: [email protected] Subject: RE: Next step towards URL gadgets - design proposal Perhaps I misunderstood your statement, but your Design Requirement 2 states: <quote> 2) URL gadget developers do not require features like Prefs.get*, log, etc... *) Some of these they would never use *) Prefs methods are replaced with server side accessing of URL parameters... </quote> If you're talking about the setpref feature, will the user have to pass session ID and some application-specific preferences as URL parameters? I thought it wouldn't be secure. From: "Weygandt, Jon" <[email protected]> To: <[email protected]> Date: 12/01/2009 09:53 AM Subject: RE: Next step towards URL gadgets - design proposal Not sure what you mean by "server side accessing of URL parameters"? -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Tuesday, December 01, 2009 7:47 AM To: [email protected] Subject: Re: Next step towards URL gadgets - design proposal The ability to handle URL gadgets "out of the box" is critical if we want Shindig to become an enterprise asset, so I applaud the effort. This said, does anyone have plans to address how URL gadgets will work in a secure environment? I don't think " server side accessing of URL parameters" plays very well here. The scenario is further complicated by the fact that Shindig will frequently be used as a "service" rather than co-hosted with the application. Would be interesting to hear how people address these needs or if there are any plans to solve this once and for all in Shindig. Thanks, Ilya From: "Weygandt, Jon" <[email protected]> To: <[email protected]> Date: 11/25/2009 01:52 PM Subject: Next step towards URL gadgets - design proposal A proposal for review and comment... I would like to implement section 3.1.3(6)(c) http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/Gadget s-API-Specification.html#process. This will not be a complete implementation for URL gadgets, but takes Shindig one step closer to the specification, and will provide a platform for which server implementers can experiment with URL functionality. Design requirements: ================ 1) URL gadget developers require features that they cannot easily replace, such as rpc, dynamic-height, set-title, views, etc... 2) URL gadget developers do not require features like Prefs.get*, log, etc... *) Some of these they would never use *) Prefs methods are replaced with server side accessing of URL parameters 3) Same origin policy makes implementing makeRequest, dataRequest impractical *) Server side calls to REST and RPC APIs are the alternative Design proposal ============= libs parameter This will be a variant of the /gadgets/js/rpc.js. It will fetch the URL-Gadget-Side JS necessary. Feature libraries, JS Servlet, Rendering Context To support a reduced set of JavaScript, and maybe even a different set of JS the changes will start with introducing a new RenderingContext.URLGADGET. "c=2" for the JSServlet. Down to the feature.xml file having a new tag <urlgadget> Some of the individual feature JS may be split apart to support inclusion in gadget context separately from urlgadget context. Currently the rendering does a redirect as part of the ifr call. I will also introduce an option into shindig.properties, whereby the metadata call will return the external URL as part of iframeurl, instead of the ifr url with a redirect. Open Issues ========== The spec does not address how one determines the "servers JavaScript request handler path". I don't propose to address this as part of this effort, since few containers will actually support URL gadgets, the developer will pretty much know who they are targeting. The issue of the gadget developer putting "foreign" JavaScript on their page introduces cross site scripting concerns for them. This is also beyond the scope of this patch, but would probably be addressed by signing the request and developers whitelisting the servers that they support. Comments ========= I would be doing the changes to the Java side of Shindig. As to the additional tag in features.xml with respect to PHP, it appears the PHP code (GadgetFeatureResigtry.php) is similar to the Java side, it will simply ignore the new tag. --------------------------------------------------------------------- The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. --------------------------------------------------------------------- --------------------------------------------------------------------- The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ---------------------------------------------------------------------
