Cassie, I think that the option 2 would be better, mainly because the Abdera is another project, and if we have to change some code in the future, doing it in the DataService would be much faster than changing code in Abdera, and then update the shindig project, plus that as Chris says, in the PHP version we use something similar to the option 2 and its more portable between the 2 versions =)
G.- On Fri, Jul 11, 2008 at 11:07 AM, Chris Chabot <[EMAIL PROTECTED]> wrote: > Hey Cassie, > > Now i don't think my opinion should be a binding vote, but i do have a > strong preference for the DataService based one (option #2). > > My main reason for that is that when i was looking at both code bases (as a > non java expert) the Abdera code base was incredibly tough to get into, and > see what it actually -did-, it seemed very fragmented and hard to trace > through; However the DataService based code was easy to follow and > understand. > > Now this probably isn't a incredibly crucial fact for anyone who's used to > Abdera's structure's, however for future contributers, and from an > anyone-should-be-able-to-maintain-and-modify-this perspective, the > readability of it does play an important factor and from my perspective > solution #2 does this right where as #1 makes this a bit harder. > > We're an infrastructure type of project so i'm not going to argue all code > should be simple or easy to understand or maintain, infrastructure work > always comes with it's complexities; However if there's no other strong > factors making one solution superior over the other, there's no reason > either to make it harder then it should be :) > > Also, and again this shouldn't be a binding reason, the PHP version of > shindig uses a structure that is very close to the #2 solution, so that > makes knowledge portable between the 2 versions, which can be quite > beneficial in a few situations (and promotes mind share between the 2 > versions) so from that perspective i'm also pro #2. > > Anyhow that's my $0.02 > > -- Chris > > > On Jul 8, 2008, at 11:34 PM, Cassie 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) >> >> 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 >> > >
