On Wed, Apr 2, 2008 at 6:35 PM, Kevin Brown <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 2, 2008 at 6:08 PM, David Primmer <[EMAIL PROTECTED]> > wrote: > > > Hi Cassie, I'm looking out for the API server and was under the > > assumption that it would be an autonomous server. After looking at the > > changes to the source tree recently (moving from the proposed > > /java/social to under /java/gadgets/../social/ it seems that a few > > small things have been done to make the API server more dependent on > > the gadget server. Maybe this is just a matter of expediency and was > > done simply to get a stub checked in to work with. But the concerns of > > the PHP dev here are basically my concerns: Java build and deployment > > decisions affecting the 'standard' way of doing things. > > > > comments below: > > > > On Tue, Mar 18, 2008 at 8:46 AM, Cassie <[EMAIL PROTECTED]> wrote: > > > My thoughts: > > > > > > 1. We should make the php stuff use the same url structure as the > java > > stuff > > > (making people change configs by hand is evil) > > > 2. The java social/* directory depends on the gadgets/* directory. > > > > Can you explain why this is. This seems wrong to me. > > > > > 3. I don't care what the url is at all, as long as people only have > to > > run > > > one server by default for the java stuff. > > > > There are two servers that have not dependencies on one another and > > they can be mounted at their own urls or on run on different servers. > > I'm a little confused about the need to get a nice 'all in one' > > reference implementation server for all of OpenSocial and how it > > balances against the need to provide an implementation that is > > designed to be deployed in a realistic server environment. The server > > as it is now can be dis-assembled and distributed but seems like this > > dis-assembly could be facilitated be taking some measures to isolate > > the components and add more hooks for application servers. > > > > > > > > Okay, so all of those mean that we either need to make the > > > gadgets/socialdata url work for php or we need to make the > /socialdata > > url > > > for for java. > > > > > > Unfortunately, for the java side things work like this: > > > - the entire running server is mapped to localhost:8080/gadgets. > > > - each servlet has a namespace under /gadgets. so the > GadgetDataServlet > > > happens to be mapped to socialdata just like the JsServlet is mapped > to > > js > > > and the RpcServlet is mapped to metadata. so social data is at the > same > > > level as all the other servlets > > > > This doesn't seem necessary. The social data (the API server for > > people, activities and appdata) is not functionally at the same level > > as these other servlets because it is not an interface for the gadget > > server. You don't need to serve gadgets to participate in OpenSocial. > > > Yes you do. You can't support opensocial without supporting the gadgets > spec > as well. They're effectively a single spec, although there's currently a > pedantic separation due to the way that the specs have evolved. > Consider three scenarios: 1. PHP API server, Java gadgets server (where the API is tightly bound to an existing PHP site). Seems like a reasonable thing to want to do, yet the PHP API server isn't serving gadgets. 2. Gadget servers running in a geo-distributed manner to minimize gadget rendering latency, while the API server is running in one or two datacenters to minimize distance-to-data. Seems like a possibly reasonable approach. 3. Gadget server functionality is outsourced to someone else (the syndicated gmodules.com scenario), while the API server is run by the organization that owns the social data. Some issues with how to communicate via JS but certainly do-able in a federated model. All of these benefit from separating the code and URLs of the two subsystems. More to the general point, it seems very odd to have a truly generic data API be modelled as a feature of the gadget server. Assuming that social gadgets use the generic API, the dependency would be the other way (gadgets depend on the API, the API does not depend on gadgets. An OpenSocial container has to provide both of course, but there are many reasons to deploy them separately.
