Hi Andrew, I've been looking around that part of the code lately as I was working on View level features (http://codereview.appspot.com/4077043/). I haven't dug into your patch yet, but I think it will probably affect you.
I don't know if not implementing it in the gadget metadata service is a bug necessarily, it's possible that nobody needed it until now. For example, Locales aren't exposed by this service either. Remember, there is a JS API for gadgets needing to access feature parameters that is part of the Core Gadget spec called "gadgets.util.getFeatureParameters()". http://opensocial-resources.googlecode.com/svn/spec/1.1/Core-Gadget.xml#gadgets.util.getFeatureParameters Matt Marum |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Andrew Davis <[email protected]> | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[email protected] | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Cc: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[email protected] | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |01/28/2011 03:14 PM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Feature Param support in Gadgets meta-data requests, Features support extensible XML contributions? | >--------------------------------------------------------------------------------------------------------------------------------------------------| We have been looking at using feature params in the current implementation of shindig. Currently we have a patch(attatched) that fixes the GadgetHandlerAPI to return feature params, and fixing BeanConverter to support MultiMap. For a feature declaration like this: <Optional feature="open-search"> <Param name="search-atom"> http://www.intertwingly.net/blog/index.atom?q={searchTerms}</Param> </Optional> The meta date request returns this(with our patch) "features":{"open-search":{"params":{"search-atom":[" http://www.intertwingly.net/blog/index.atom?q= {searchTerms}"]},"name":"open-search","required":false} Basically any thing inside the <Param> can be returned as in the meta data request So this may be a spec question, but given where the implementation is today, first wanted to check on shindig dev what the intention of feature params are. Conceptually has anyone considered a generic mechanism to allow features to contribute arbitrary XML, and easily integrate existing standards? In this example open search description. <Optional feature="open-search"> <Param name="description"> <OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/ "> <ShortName>Web Search</ShortName> <Description>Use Example.com to search the Web.</Description> <Tags>example web</Tags> <Contact>[email protected]</Contact> <Url type="application/rss+xml" template="http://example.com/?q={searchTerms}&pw= {startPage?}&format=rss"/> </OpenSearchDescription> </Param> </Optional> We can with our patch, escape the XML of course like this: <Param name="action3"><![CDATA[<action title="foo"/>]]></Param> and the XML will be returned as a string in the gadget meta-data request, but then we have XML on the client/container page to parse. Has anyone considered leveraging metadata request to transform arbitrary XML into corresponding JSON? Was not implementing feature params just a bug or done specifically for performance reasons? MetaData request parsing extremely large feature contributed XML could increase load on the server, but would be a clean extensible mechanism for features to extend the specification within the schema and allow the container to access those extensions as JSON. Thoughts? --Andrew Davis
