On Mon, Apr 14, 2008 at 3:07 AM, Cassie <[EMAIL PROTECTED]> wrote: > to follow up on this change I am trying to move the social/* classes > out of the java/gadgets package and into java/social-api > > the social classes have the following gadgets dependencies: > > // security token stuff > import org.apache.shindig.gadgets.GadgetException; > import org.apache.shindig.gadgets.GadgetToken; > import org.apache.shindig.gadgets.GadgetTokenDecoder;
These last two belong in the separate shared package, ultimately. For now, import the gadgets artifact. The first one should become an exception type specifically for dealing with the tokens. Rename to "SecurityToken" and "SecurityTokenDecoder" // guice stuff > import org.apache.shindig.gadgets.http.InjectedServlet; (and friends...) This should actually come directly from Guice ultimately. Louis Ryan was attempting to figure out how to get the servlet extension for guice available. If we can't get it integrated soon, we'll probably move it to the shared project as well. > > > // fetching remote file stuff > import org.apache.shindig.gadgets.BasicRemoteContentFetcher import org.apache.shindig.gadgets.GadgetException; > import org.apache.shindig.gadgets.RemoteContent; > import org.apache.shindig.gadgets.RemoteContentFetcher; > import org.apache.shindig.gadgets.RemoteContentRequest; Shared (not rendering specific). > > Anybody have any ideas/opinions as to how we handle these things? > > Also - would people prefer that the social-api host the > samplecontainer, or the gadgets server? Same goes for the rest of the > javascript samplex.html and other files. Since all of these demos are rendering gadgets, they should remain packaged with the gadgets server. > The gadgets server will still > serve the opensocial gadget js. No matter which one we pick we are > going to need to do some sort of forwarding servlet or proxy thing or > a config of some sort which puts the gadget iframe url on the same > domain as the socialdata servlets so that the js can xhr. Any opinions > on this piece? I think we're conflating the opensocial js feature and the restful stuff too much as is. I'd prefer that the common interfaces and whatnot go into the shared project, while the stuff that's specific to handling the opensocial gadget feature be packaged with the gadget renderer and the stuff that's specific to handling the restful apis be packaged with the restful api server. I'm still not seeing what the value is in cramming all the socialdata stuff into the same place as the restful api server, when it's clearly stuff that needs to be shared between both servers. -- ~Kevin
