On Wed, Apr 2, 2008 at 8:20 PM, David Primmer <[EMAIL PROTECTED]> wrote:
> In 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: > > > 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. > > > > You're right about supporting opensocial. What I meant by "participate > in opensocial' was similar to what John outlined below, where the > person implementing the server could only be doing the data api part > of the "support" of opensocial and some other server or even other > company could provide the other aspects. Didn't mean to confuse > matters. Of course -- the gadget rendering components can (and should be) logically separated from the API server. A monolithic production setup would be difficult to maintain, and I shudder to think about the pain we'd have to go through for actually implementing it in Shindig! :) What exists in the "social" package right now is the wiring for making the opensocial javascript libraries work. More likely than not, there will be significant overlap between this code and the API server code. Figuring out the logical separation there is important to allow the social API server to develop independently of the gadget rendering server.
