On Thu, Apr 3, 2008 at 2:27 AM, Cassie <[EMAIL PROTECTED]> wrote: > 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.
I think that ultimately there are 2 servers and 3 projects (aside from the container page itself, of course): - Server A / Project A The gadget renderer, which *includes* connections for the opensocial javascript APIs, even if they're little more than delegation to an RPC channel. - Server B / Project B The data server, which should probably include the RESTful wire format. - Project C: Common stuff. OAuth stuff belongs here as well. This isn't a standalone server, it's common code used by both the gadget rendering server and the social API server. Recycling the JSON RESTful binding for use in both the gadget server and the API server would be awesome, but it isn't a strict requirement. Everything except the most trivial deployments is going to want that separation. If you want 1 command to kick off both servers, that's what we have shell scripts for (maven can probably do this anyway though). One monolithic server will be a nightmare to maintain, and it makes little sense in a real world production scenario. -- ~Kevin
