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>ad...@example.com</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
