That looks clean enough, but not sure it will really work in json. If you have multiple params with same name, won't it create a json hash with multiple items with same key? I rather just add another function to feature that list params as list instead and expose that. Let the client consumer create map if needed.
Proto buffer is just a data format that we used in our internal rpc, see http://code.google.com/p/protobuf/ We currently don't need to extends the spec. Ziv On Sun, Jan 30, 2011 at 1:33 PM, Andrew Davis <[email protected]>wrote: > Ziv, > > Sorry meant to send the patch. Would really like to get feedback on what > the original design intention/implementation plan was for feature params. > > What is your proto buffer api doing? Are you looking to allow features to > extend the spec through feature params? > > --Andrew > > > On Fri, Jan 28, 2011 at 8:37 PM, Ziv Horesh <[email protected]> wrote: > >> Yes, the parameter were not implemented in GadgetHandler because we didn't >> need them at that point, and we would add them when needed. >> I am curious to see your patch to support multimap (I will need figure out >> a >> way to support in my proto buffer api that inherit this). >> >> >> >> On Fri, Jan 28, 2011 at 2:19 PM, Matthew G Marum <[email protected]> >> wrote: >> >> > 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 >> > >> > [image: Inactive hide details for Andrew Davis ---01/28/2011 03:14:25 >> > PM---We have been looking at using feature params in the current]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}<http://www.intertwingly.net/blog/index.atom?q=%7BsearchTerms%7D> >> </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 >> > >> > >> > >> > >
