My my - quite a thread happened while I was sleeping. There were like 20 million things that came up, so let me try to address some of them.
1. For complying to the opensocial spec you -must- be able to render and correctly display gadgets. Opensocial the spec relies on the gadget spec. There is dependence there and it is explicit. 2. Alright, so David was talking about something else - and that is purely technical. The /social/* code depends on some of the same infrastructure that the gadgets code does. It's not anything special, it used to be the CrossServletState (now guice) and the GadgetToken stuff. OpenSocial relies on GadgetTokens to do security things. social/* doesn't need anything oauth at the moment, but it will when the server-to-server apis get in there. 3. Given #2 I wanted to get some code in there quickly. The easy way was to put it on the same server to get all of the same benefits. That's the only reason I did it. And we can change it to whatever fits out needs too. However, I would like to see us have a couple of things satisfied. a) in dev - it would be nice to run just one command that runs everything and allows the samplecontainer to work. (the samplecontainer relies on both the gadgets server and the socialdata stuff) b) in prod - it would be nice if it were easy to run 2 deployments or 1 deployment c) the server that hosts the socialdata servlet should also host the javascript. Otherwise, you've got two halves of the wire format on two different servers - and that just seems like a recipe for disaster. (the samplecontainer should maybe also live in the social server but it uses everything.. so i'm not really sure how we will want that to work) I don't know how to do this. So, if someone can send in a patch that fixes all the maven stuff up to make that happen then let's go for it. In addition, we would probably need to do a directory shuffle like what Kevin described where we explicitly mark things as common or whatever. 4. Lastly - the RESTful server should be the same server as the socialdata server. They read from the same backends, and produce the same kind of thing (a wire format that somebody can depend on - like javascript). So, I don't think we need to make 3 servers. Hopefully the socialdata code and the RESTful code will be one and the same and the wire formats will be one and the same. That's what we should strive for just from a "duplicate code is evil" perspective. People have already filed bugs against us to do just that, and we will get there - but the RESTful spec needs to be done, and the code needs to be implemented. Until then, we will keep working on the current stuff to make it usable. Hopefully, most of the code we have in social/* can be reused in some manner. But anyway, that's more long term as nobody has started implementing anything in that area yet. Alright, I hope I didn't add more flame to the fire. Hopefully it makes some sense. - Cassie On Thu, Apr 3, 2008 at 8:37 AM, Kevin Brown <[EMAIL PROTECTED]> wrote: > > On Wed, Apr 2, 2008 at 11:11 PM, Brian Eaton <[EMAIL PROTECTED]> wrote: > > > On Wed, Apr 2, 2008 at 10:41 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > > > The shared pieces are the data accessors (both the JS and REST APIs need > > > these). Ideally I'd like to see the wire format used by the JS APIs to > > > communicate with the back end being identical as that of the JSON > > bindings > > > for the RESTful state, although that's not a strict requirement. > > > > My guess is stuff in the util/* directory will end up being useful as > > well. > > > > Agreed. > > Is anyone familiar enough with maven that they might show me how (or even > provide a patch!) that would let us have 3 separate projects? Something > like: > > trunk/java/gadgets <-- everything under the org.apache.shindig.gadgets > package > trunk/java/rest <-- non-shared parts of the RESTful API > trunk/java/common <-- everything shared > > I'd expect some parts of org.apache.shindig.gadgets to move into "common" > (OAuth bits mostly, I think), and everything currently in the > org.apache.shindig.util package as well. We could drop the util stuff into a > completely separate package as well. > > There is already a top level pom.xml, so I assume that we can just create > pom.xml files for the other two directories and then set up dependencies > appropriately. I have no idea how to make that happen though -- this is the > first maven project I've ever worked on. > > -- > ~Kevin >
