On Mon, Apr 14, 2008 at 1:32 PM, Cassie <[EMAIL PROTECTED]> wrote: > > 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 :)
If we're completely confident that the gadget-side opensocial js code can talk to the RESTful servlets without modification, then I think we're completely covered. Running these things as a single server really isn't an issue. We can always provide a single war file that packages up both the RESTful stuff and the gadget rendering stuff and registers both gadget rendering and RESTful API servlets. We still need the third package though, so that the OAuth / security / other shared stuff has a place to live and there aren't any hard dependencies between them. It's also *highly* likely the gadget rendering server will need to preload some social data at rendering time, which means that it will need to use the social data interfaces (not servlets or wire format adapters or anything like that). I'd much rather have the gadget renderer get these interfaces from the common project than depend directly on the RESTful project. -- ~Kevin
