On undefined, Nick Lothian <[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. > > This is true but perhaps it shouldn't be. > > For a variety of reasons we aren't overly interested in the ability of > users to deploy Gadgets themselves at the moment and we already use other > technologies for integrating the UIs of applications. > > However, a standard way of manipulating the social interactions of users > and integrating those interactions across applications on the serverside is > something that interests us greatly. > > That means we are much more interested in a standalone API server than one > integrated into a gadget server - the gadget stuff is something we just > don't want to have to worry about at the moment. >
I suspect this could be a pretty common case. A variety of UI tools and desktop applications can immediately start integrating with the API Server and consume the data, without actually implementing gadgets. But is there any TECHNICAL reason why the gadget server and API server should be tightly coupled in this manner? could someone elaborate on that please? thanks > Nick > > > IMPORTANT: This e-mail, including any attachments, may contain private or > confidential information. If you think you may not be the intended > recipient, or if you have received this e-mail in error, please contact the > sender immediately and delete all copies of this e-mail. If you are not the > intended recipient, you must not reproduce any part of this e-mail or > disclose its contents to any other party. This email represents the views of > the individual sender, which do not necessarily reflect those of > education.au limited except where the sender expressly states otherwise. > It is your responsibility to scan this email and any files transmitted with > it for viruses or any other defects. education.au limited will not be > liable for any loss, damage or consequence caused directly or indirectly by > this email. >
