>From all I've heard, this is the key observation being made by those who say that Abdera is overblown for this particular task. At a high level, what's involved here is: 1. Parse data from format X into Java objects. 2. Dispatch to service handlers. 3. Convert results into format X.
On superficial analysis, this suggests only the need for format-translators and nothing else. Json-lib and json.org's libraries fit the bill from the JSON side. If Abdera is modular enough to accommodate simple InputStream-to-intermediate-Object (thence, to dispatchable Java object) parsing - and back - with little overhead, then great. If not, perhaps something like Rome is the way to go. Cassie's comments suggest that this is true. Perhaps this is a lack of understanding of Abdera, but learning curve is as much an issue as the minimal amount of code required to get something done. --John On Wed, Jun 11, 2008 at 3:47 PM, John Panzer <[EMAIL PROTECTED]> wrote: > Just a quick note -- the difference between the JSON RESTful API and the > AtomPub RESTful API is fairly minimal at a high level; all the actions, > URLs, and patterns are the same, and all based on AtomPub throughout (and > in > the batch interface, you can even mix the two). The only difference is the > data format (format=json or format=atom) and there's a 1:1 mapping between > the two formats so they're structurally alignd. Without getting into > whether Abdera is the best starting point or not, it'd be surprising if > there were not nearly 100% commonality in everything except the > serialization code. These aren't two APIs; they are one API with two > flavors of data. > > (Very tempted to add an optional format=csv data flavor to the spec, just > for fun...) > > On Tue, Jun 10, 2008 at 5:43 PM, David Primmer <[EMAIL PROTECTED]> > wrote: > > > On Tue, Jun 10, 2008 at 3:58 PM, Cassie <[EMAIL PROTECTED]> wrote: > > > As Kevin mentioned though json->pojo->json is the easiest part of all > > this > > > because it is already done within shindig. Our small utility class does > > > everything it needs to do and no more. It isn't fancy and we could > > > definitely replace it later on with something more standard, but for > now > > > that's all taken care of. > > > > > > All we really need to do for rest is write a simple servlet that maps > the > > > restful url patterns onto correct handlers and pulls out the url params > > that > > > each of the handlers need. And then we need tests. It should be super > > simple > > > (like maybe 2 additional classes with potential copies of the *Service > > > interfaces and the OpenSocialDataHandler for now because they don't > quite > > > fit rest.) > > > > I had assumed that "all we really need to do for rest" is the same as > > the OpenSocial 0.8 spec. However, the task that document outlines is a > > lot longer than the one the paragraph above describes. There are a few > > more aspects of that spec, including batching, partial updates, > > merging auth context with request url context, paging and concurrency > > control. Will all these be done twice? > > > > > > > > This is why I think abdera was a silly choice for us - this code should > > be > > > dead simple and abdera was making our lives non complicated. However.. > > the > > > atom is more complicated than the json, so maybe it is a better fit? > > > > The answer depends on what your perception of "us" is, I think. How do > > you plan on running the two servers concurrently, both answering the > > same url patterns but one taking the requests of ?format=atom and the > > other taking requests with the param ?format=json ? > > > > > > > > - Cassie > > > > > > > > > On Tue, Jun 10, 2008 at 3:53 PM, Ian Boston <[EMAIL PROTECTED]> wrote: > > > > > >> I should have read the rest of the thread before posting, sorry. I was > > >> forgetting just how big the Person object was and just how compact > > >> annotations are.... and then there will be the pain of maintenance > > >> with anything that large hand coded. > > >> > > >> We might be talking about different jsonlibs ?, > > >> http://json-lib.sourceforge.net/usage.html does both ways serialize > > >> and parse, based on getters and setters..... but I suspect the hand > > >> coding is still a killer and mapping may be a pain, so annotations > > >> still win (IMH and better informed O :) ) > > >> > > >> Ian > > >> > > >> 2008/6/10 Kevin Brown <[EMAIL PROTECTED]>: > > >> > On Tue, Jun 10, 2008 at 3:12 PM, Ian Boston <[EMAIL PROTECTED]> wrote: > > >> > > > >> >> I have had good experiences with trees of maps and lists containing > > >> >> primitive types, serialized by json-lib. The same trees are easy to > > >> >> serialize using the apache xml-rpc libraries, and appear to > stack-up > > >> >> reasonably well underload. Its not sophisticated, but it is fast to > > >> >> work with, light on the GC under load and appears to perform well. > > >> > > > >> > > > >> > The JSONObject library being used right now handles primitives and > > >> > containers already (JSONObject.put(Map), > JSONObject.put(Collection)), > > as > > >> > well as bean-style objects (JSONObject.put(Object)). That doesn't > > handle > > >> the > > >> > conversion back, though, which is where a library would come in > handy. > > >> > > > >> > This isn't just an issue for the social data, either -- the metadata > > >> handler > > >> > is currently doing all this by hand, and it would be much more > > convenient > > >> to > > >> > just have an annotation processor or something along those lines. > > >> > > > >> > > > >> >> > > >> >> I was going to try abdera in another project, now I am not so > sure. > > >> >> > > >> >> 2008/6/10 Cassie <[EMAIL PROTECTED]>: > > >> >> > We tried to use abdera to implement the opensocial json restful > > format > > >> >> > within Shindig.. and it didn't work out very well. The code is > > clunky, > > >> >> > overly complicated for simple json and is hard to come up to > speed > > on. > > >> >> > > > >> >> > So... I am going to try an alternate implementation based on the > > >> existing > > >> >> > older json wire format code. I was going to start coding > something > > in > > >> a > > >> >> > separate dir so that none of the current code is disturbed. > > Hopefully, > > >> in > > >> >> > the next couple days we will have a cleaner impl of the restful > > json > > >> that > > >> >> is > > >> >> > 90% the same as all of the current social code. (this means less > > >> >> migration > > >> >> > for current social code users too, yea!) > > >> >> > > > >> >> > And as for atom... well, we can figure that out later :) > > >> >> > > > >> >> > Please let me know if you have any huge objections to this. > > >> >> > And of course, if it turns out to be worse than the abdera impl.. > > we > > >> can > > >> >> > always go back. > > >> >> > > > >> >> > - Cassie > > >> >> > > > >> >> > > >> > > > >> > > > > > >
