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.
