On Wed, Jun 11, 2008 at 6:12 PM, John Hjelmstad <[EMAIL PROTECTED]> wrote: > 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.
Maybe I should give a more fleshed out example of what actually needs to happen to process a request by the server. It will take a while but maybe put "to rest" the perception that the server is just a format translator. Here's a short version: On significant difference here is that this is a REST server so the urls mean something. They have semantics that need to be parsed and processed, both on writes and reads. It's not just an endpoint that you send requests to that funnels that directly back to a service handler that has all the logic for fulfilling a request. I know this is the way some of this was done in the past and it seems like annoying to not be able to simply continue this chain of RPCs all the way from the js to the data service layer, but we're trying to add a REST server that speaks Atom Pub and Json. In effect, since the 0.8 spec is approved we've said "we're going to take a 100% RPC-based system and stick an annoying custom Atom Pub REST interface right in the middle of the chain. I welcomed the challenge because I think it's a valuable thing to do. Coding it up exactly as the spec dictates makes it a hard problem. If the spec only said, "generally obey REST design principles", we could use any ol' readymade framework that could instantly publish our java objects, such as enunciate, and call it done. davep > > 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 >> > >> >> > >> > >> >> >> > >> > >> > >> >> > > >> > >> >
