Just responding to your last comment very quickly: On Mon, Apr 14, 2008 at 8:54 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > 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.
Very soon - there won't be any "socialdata" stuff. There will only be the restful api server. It will gloriously serve the restful apis from whatever db backends someone wants to use. The opensocial javascript in the features directory will use the restful wire format to get data from the server and set data on the server. It will no longer use the temporary json thingy that it does now (unless we utterly fail). The sample container will still exist (and David, its already in its own root, that's not the issue - it's more about which server -serves- it and the other javascript/* files). When the sample container exists it will need gadgets in iframes. These iframes have to point to the gadget rendering server.. and they also need to xhr back to whatever server they are getting social stuff from.. thus, the need for something to be able to handle that. I don't believe this shows an overlap between the two servers or anything.. it just simply needs to be done in order to satisfy same domain goodness. But hey, why do you think I put the socialdata stuff on the already existing server in the first place? It is much much easier :) - Cassie > > > -- > ~Kevin >
