Thank you very much. Let's see if I get this right: If I run a gadget written for OpenSocial 0.7, then the GadgetDataServlet class will be used; If I run a gadget written for OpenSocial 0.8, then the RestServlet class will be used.
I found 3 sample gadgets that require OpenSocial 0.7 - all are in \shindig\javascript\samplecontainer\examples: SocialHelloWorld.xml, SocialActivitiesWorld.xml, getFriendsHasApp.xml If I run them on my server, will I be able to see that the GadgetDataServlet class is used? Are there any sample gadgets that require OpenSocial 0.8? Efrel 2008/7/3, David Primmer <[EMAIL PROTECTED]>: > > I think there are previous posts about this issue somewhere on this > list. There is no current global picture. It's kinda hard to write > global pictures and keep them updated when stuff changes so fast. This > is a pain for people who just want to use the latest and greatest and > I think this is just the way it goes. > > Anybody want to jump in and clarify, please do. Cassie is probably > best suited to this task but she's on vacation for a few more days. > > Currently there are 3 different wireformat/apis served by the stuff in > java/social-api and, I think 4 different codebases that do different > parts of those formats. > > - one is the gadgets server to api server back channel rpc system that > allows a gadget server to manage the persisted info about it. it's > doing operations on data that is not part of the social data model, > but just container specific utility functions. > > - two is what we've affectionately called 'casse wire protocol' which > is getting the request in postdata > > - three is the 0.8 Restful API spec wire format. > > > Of these, there are different servlets covering some or all of them. > > RestServerServlet handles case one and three. > > GadgetDataServlet, I believe handles case one and two. > > DataServiceServlet, I think handles only case three. and only in json. > > The eventual goal is to handle case one and three. I don't know if the > wire format or protocol of case one is going to be updated any time > soon. It's sorta shindig-specific and I don't know how much it is > used. I've only seen the code under RestServerServlet (abdera) that > does stuff like 'doevil' with 'setEvilness'. I'm clueless about it. > > There are other code branches mixed in here as well that are not > necessarily tied to a specific servlet. > social/dataservice/DataServiceServlet has a new json-only > implementation recently contributed by cassie and doesn't use abdera > at all and has some new data interaction. I have a patch that is not > committed that uses some of cassie's work but keeps the abdera servlet > and routing system. Things are branching as we're evaluating > implementation strategies. The dual nature of RESTful spec has many > confounded. We'll be working this stuff out in the coming weeks and > hopefully begin to purge earlier experiments from the code. Right now, > we're leaving them in. > > Ok. so there's your summary until the next time someone asks. > > davep > > > > On Thu, Jul 3, 2008 at 11:54 AM, Erel Segal <[EMAIL PROTECTED]> wrote: > > RestServlet and GadgetDataServlet apparently do similar actions: they get > > requests for social-network data (about people, personal data or > activities) > > and return responses. There are several noticeable technical differences, > > such as: > > * RestServlet is used for URLs such as " > > http://myserver.com/social/rest/people/...";, " > > http://myserver.com//social/rest/activities/...";, " > > http://myserver.com//social/rest/appdata/...";, and takes the input from > the > > URL, while GadgetDataServlet is used for URLs such as " > > http://myserver.com//social/data..."; and takes the input from the > > $_POST['request'] parameter. > > > > > > However, I would like to know the functional place of each servlet in the > > global picture. Why are they both needed? > > > > I read the excellent documentation by Rajdeep: > > http://rajdeep.dua.googlepages.com/shindigPHP-overview-tidy_img.html > > but it doesn't relate to RestServlet. > > > > Thanks for the explanation! > > >
