Matt, the gadget API does not help much because we want the container to have access to this information. For example a gadget can contribute its search to a common search area in the container.
Andrew and Igor, now that I am thinking of this use case I have some more questions about why we want implement it this way, but those are spec related questions so I will hold off on the those until the proposal is out. -Ryan Email: [email protected] Phone: 978-899-3041 developerWorks Profile From: Matthew G Marum/Raleigh/IBM@IBMUS To: [email protected] Cc: [email protected], [email protected] Date: 01/28/2011 05:19 PM Subject: Re: Feature Param support in Gadgets meta-data requests, Features support extensible XML contributions? 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 Andrew Davis ---01/28/2011 03:14:25 PM---We have been looking at using feature params in the current implementation of shindig. 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]></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
