[SHINDIG-1258] Shindig fails to support the "libs" parameter for URL Gadgets

The render of a URL gadget requires "libs", Gadget Specification, Section 3.1.3.6(c): http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/Gadgets-API-Specification.html#process

The attached change will generate a libs parameter, suitable for adding to the "JS path", which for Shindig is: http://xxx/gadgets/js/. However the Gadget Specification is silent on what that is, and how it is communicated to the gadget developer. I remember for iGoogle, they simply documented the string. Additionally there are security and trust issues with gadget developers including foreign JavaScript. This patch will not attempt to address these issues.

Additionally there is a new parameter "unsup" to report unsupported features to the remote site, reference Gadget Spec 3.1.3.5(a).

Overview of the changes:
*) RenderingContext - added a new enum URLGADGET
**) c=2 ==> URLGADGET for URLs
**) Made several changes to propagate that throughout the code base

*) For the feature.xml files added <urlgadget>
**) Updated the feature.xml for features that should work, in general my thoughts are anything a URL author cannot do another way should be supported (e.g. rpc and related functions like dynamic height, info on views). Things like user prefs, message bundles, etc... all have "another way" and are not supported. Also most of the opensocial calls have "another way" (e.g. REST/RPC).

*) JS Servlet now responds to c=2
**) Not only does it return the JS itself, but it will also return the container configuration, which is normally part of the gadget rewriter (which is not called for a URL gadget).

*) The URL Generator will return with the remote URL with the metadata, which eliminates the return trip to the server.

[Jon Weygandt, 2010-01-08 20:20:54]

Fixed the parse errors of the first patch

[chirag, 2010-01-09 05:28:34]

http://codereview.appspot.com/184041/diff/18/22
File
java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/JsServlet.java
(right):

http://codereview.appspot.com/184041/diff/18/22#newcode180
java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/JsServlet.java:180:
sb.append("//Errors: ").append(e.getMessage());
This means we're leaking the exact internal server error.

[Jon Weygandt, 2010-01-11 21:45:29]

Fixed the leak of internal server error

[Paul Lindner, 2010-03-23 07:38:03]

Seems good to me.  I'd like to hear what John and Ziv have to say about this
since they've been spending some quality time in this section of the code.

[johnfargo, 2010-03-24 00:26:23]

IMO this is an interesting approach, but I'm exceedingly skeptical of changes
that continue to bake in what's a rather broken gadget "type" in the first
place.

To some degree this is a philosophical can of worms, but IMO type=url gadgets
aren't really gadgtes. They're in practice an overwrought way to generate an
IFRAME URL that, in turn, performs a <script src> back to some home server.
What's more, existing ones (per iGoogle docs) can really never work w/o iGoogle
perpetually hosting script or the gadgets themselves changing.

The uses I've seen for these are:
1. Auth. IFRAMEs just "happen" to get the same cookies as their containing app,
thereby avoiding having to support OAuth.
2. Traffic/usage measurement.
3. Turning a page-into-a-gadget.

The only real functionality you get from the gadgets framework in this case is
rpc.

#3 typically doesn't really use gadgets JS. Types #1 and #2 can be achieved by
IFRAME-in-a-type-html-IFRAME. This involves a home-baked protocol for talking
btw the "gadget" frame and the "target," which you're essentially inventing
anyway when you write a url gadget (having to sanitize what you script src). If
the target server(s) in #1 support OAuth, you can just convert to type=proxied
(type=html href=<URL>). #2 is largely covered by proxied-mode as well.

So my primary preference is to convert or treat as proxied existing type=url
gadgets. But assuming these things are an inevitability (and they may be, if
only for their uniform packaging format w/ other gadgets; I've been complaining
about them for almost 2 years! :)), code review is:

* Could you sync/resolve and re-upload a patch? Codereview is having trouble w/
old code and the fact that this is on incubator SVN still.
* Note that UrlGenerator is going away in a little bit, replaced by
IframeUriManager and JsUriManager (and OAuthUriManager). A parallel impl in
DefaultJsUriManager would be nice.

Sorry to be a pain; but given the substantial pain we've endured hacking around
type=url's limitations I felt it worthwhile to raise overarching concerns.
Thoughts welcome.

--j