On Wed, Jul 1, 2009 at 9:54 AM, Wang, Jeff (CTSI) <jeff.w...@ucsf.edu>wrote:
> 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<http://localhost:8080/gadgets/files/samplecontainer/examples/getFriendsH%0AasApp.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? Apples and Oranges :). The /gadgets/files/ path is just a place where a bunch of static files are served. It's where some of the sample gadgets themselves live. /gadgets/ifr is where gadgets actually get rendered. > > > 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. If you're concerned about such attacks, you would want to download and store files locally, but, again, you shouldn't be doing anything with the author's content without their consent. As long as you make your platform behavior well known and are only storing gadgets where the author has consented, you're probably fine, but beyond that you should probably ask a copyright attorney what is acceptable. > > > 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. > > >
