Thanks Kevin for the answers, I have follow ups to two parts of your answers.
a) With regards to the <Shindig>/gadgets/files format, it is used in the examples, e.g. at http://incubator.apache.org/shindig/getting-started.html Most of them refer to the sample container, but some of them, such as http://localhost:8080/gadgets/files/samplecontainer/examples/getFriendsH asApp.xml refer to an actual gadget. Based off of your answer, I gather that the ifr way is the way to go, and the files way should be ignored? b) This poses problems for most enterprise deployments of OpenSocial applications. Most deployments of an application requires control over the version of the item being deployed. There is no way to know, for example, that a referred to gadget spec will stay there, or even be hosted by the same people. What happens if someone had figured out a session fixation attack, and the gadget that we deployed just happened to run out of domain registration, and somebody swooped it up and replaced it with an attack? Or someone hacked into a server for a gadget, and replaced the xml? There are lots of such scenarios to deal with when we're talking about unknown third party hosts. If we just simply download the gadget spec after the vetting, and host it ourselves, there would be no such concerns. We're not trying to modify the gadgets, (nor do we want to) we're trying to prevent un-anticipated modifications of these gadgets. Thanks again! Jeff -----Original Message----- From: Kevin Brown [mailto:e...@google.com] Sent: Wednesday, July 01, 2009 12:06 AM To: shindig-dev@incubator.apache.org Subject: Re: Beyond the Examples On Wed, Jun 24, 2009 at 7:22 PM, Wang, Jeff (CTSI) <jeff.w...@ucsf.edu>wrote: > 2) Gadget deployment > > a) For a given gadget written locally, is it better to use the > <Shindig>/gadgets/files/... format, or expose the xml spec as an URL, > and refer to it in the <Shindig>/gadgets/ifr... format? I don't really know what this means. What is the <Shindig>/gadgets/files/... format? /gadgets/ifr is the location where gadgets are rendered. Where you choose to host gadgets themselves is up to you. Most containers simply allow an author to register a gadget in some sort of directory, but leave the gadget spec itself on developer-controlled servers. Shindig just assumes that the "url" parameter to /gadgets/ifr points to some valid url that can be loaded through the GadgetSpecFactory and MessageBundleFactory. By default these just perform HTTP fetching through the HttpFetcher interface, which is a thin layer on top of the Apache commons HttpClient library. > b) For a given external gadget, say, the ToDo example. Is it better to > refer to the external URL, or to download it and save it locally to > avoid potentially unwanted version update? Would that be rude to the > gadget developer? Not just rude, it might have legal consequences. You should generally avoid doing anything with someone else's creation unless you're sure that you're using it in a manner that the author consented to.
