On Tue, Jul 8, 2008 at 5:34 PM, Cassie <[EMAIL PROTECTED]> wrote: > Hello Shindig friends - > > As I'm sure most have you have picked up at least somewhat, there are two > main implementations of the RESTful opensocial spec within the java Shindig. > They are both complete enough to give a good idea of what a finished > implementation would look like which means that we should really decide on > one impl to focus on. So, I am starting this thread in the hopes that we can > objectively evaluate both options and come to a consensus on which one we > should follow through with. > > It would be great to get everybody thinking along the same lines so that we > can finish implementing the restful spec and get that much closer to full > 0.8 support! > > Here is a brief outline of the two java options: > > > 1. Implementation based on abdera. > Most code is located in the shindig.social.abdera package. > > Note: When evaluating look at the PersonJsonAdapter and PersonAdapter > implementations as they are the most updated. (as opposed to activities and > appdata) > > - shindig/social/RestServerServlet handles all requests > - the SocialRouteManager sets up the mapping from url and format (json vs > atom) to the right adapter > - the adapters (6 total, 3 in the atom folder, 3 in the json folder) get the > data from the corresponding social services. > - the atom adapters use abdera to translate the response into proper atom > format > - the json adapters use the JSONFilter and SimpleJsonAdapter (which uses the > beanJsonConveter) to talk the proper json format on input and output > > > 2. "DataService" (similar to the old wire format GadgetDataServlet) > Most code is located in the shindig.social.dataservice package. > > - DataServiceServlet handles all requests and dispatches to ActivityHandler, > AppDataHandler, PersonHandler which are injected in a url to class guice > map. > - The three handlers translate from the url pattern to the corresponding > social services. > - The handlers all return Futures so that all data fetches get executed at > the same time can then be batched. > - The DataServiceServlet (via the beanJson and beanXml converters) handles > the translation from java to xml or json. > - The xml format is not yet spec compliant - it needs to be more atomy. this > code would go inside the beanXmlConverter class > > > > Alright, so the code is all in the java/social-api section of the trunk. > Please look around and comment on the pros and cons of each set of code. > (and note, there are definitely still todos and ugliness in both packages.. > they are prob both around 80% complete)
Unfortunately you seem to have conflated two questions together. The first questions is whether to use Abdera or to write your own AtomPub implementation. The second question seems to be whether implement AtomPub or an RPC protocol with an XML serialization. The first question is really a development issue and if you have good enough libraries to lean on that do all the right things with HTTP than rolling your own implementation shouldn't be that hard, and as has been pointed out later in this thread there are tools available to make sure your impl is compliant. I've written one myself: http://bitworking.org/news/310/Update-for-AppClientTest http://code.google.com/p/feedvalidator/wiki/AppClientTest Example output: http://bitworking.org/projects/apptestsuite/client/test.html Tim Bray has also written the APE: http://www.tbray.org/ape/ The second question is rather easy to answer, if you feel the need for shindig to have a RESTful XML based API for non-browser clients then implement AtomPub. Implementing something only vaguely resembling AtomPub is only going to confuse people and also hurt adoption since there won't be ready made clients, test suites, etc. Regardless, that discussion should take place on the OpenSocial list and not this one if I understand things correctly. As for complexity I'm not well versed in Java, but I can tell you that implementing a spec compliant version of AtomPub doesn't take much code. Here is an implementation I did a few years back: http://bitworking.org/projects/apptestsite/view/admin.py The file is about 300 lines of Python code, the actual AtomPub implementation is about 200 lines of code and that is about twice as long as what you would be looking at since I implemented both Entry and Media collections and all the open social specs I've seen only include Entry collections. > > And if anybody has a better idea for figuring out how to get us all on one > code path for the java restful impl I'm all ears! > Thanks. > > - Cassie > Thanks, -joe -- Joe Gregorio http://bitworking.org
