You've got it backwards. You should have an opensocial-0.7 feature which depends on your container implementation (alternatively, just rename your implementation to opensocial-0.7). This way when gadget authors specify:
<Require feature="opensocial-0.7"/> It uses YOUR implementation of opensocial-0.7, which can only qualify as a valid implementation if it conforms to the opensocial-0.7 spec. This problem should be addressed in Shindig proper in the near future, but for now that's your only real option. ~Kevin On Jan 30, 2008 11:34 AM, Reinoud Elhorst <[EMAIL PROTECTED]> wrote: > > What does your hyvescontainer feature do/supply? > > > > We're currently thinking about how a shared server can satisfy the needs > > of > > several different containers when they have slightly different > > configuration > > parameters, data formats, and so on. Container-mediated communication > > (gadget-ifpc-to-container and back) is in many cases a viable solution > > since > > it offloads container-specific logic to the container itself, but as > > mentioned several times can have performance costs. > > > > --John > > > The hyvescontainer feature is just a copy of the relevant parts of the > opensocial-samplecontainer feature. I haven't dug into this too much yet, > but basically all logic on how to talk to the Hyves backend is in there. > > The only time the container is able to pass anything to the (shared) > gadget > server, is in the src part of the iframe. My initial idea would be to add > a > parameter to this call: extra_feature_list, which would be a list of urls > of > feature.xml files to be included in the gadget. These external feature > files > would be handled just the same as internal feature.xml files, our > hyvescontainer feature file would be something like: > > <feature> > <name>hyvescontainer</name> > <gadget> > <dependency>opensocial-0.7</dependency> > <script src=" > http://www.hyves-static.nl/opensocial/hyvescontainer.js > "/> > </gadget> > </feature> > > (I have to admit, I'm not completely sure what else is possible in feature > files, possibly this would open up a security hole. The minimal > functionality needed is just what I mentioned above: some way to set > dependencies, and some way to include javascript) > > > Reinoud >
