Let me preface my vote with a couple of opinions I have about the spec some of which I believe have led us to this point.
- The intent should have been to design the spec to support JSON first and make accommodations to allow ATOM, not the other way around. This is because the overwhelming majority of traffic from 3rd party servers will be for the JSON format. I hold this opinion based on the conversations I've had with gadget developers and on observed behavior maintaining Orkut. - The spec says MUST for both ATOM and JSON whereas I believe it should have been MUST for JSON, MUST for JSON batch and SHOULD for ATOM. As a container implementer I want batch badly for performance reasons. A batching mechanism for JSON should not rely on multi-part. - Even if the spec doesn't explicitly say it, I believe the intent was for full ATOM rfc compliance, and I agree with the folks who say it would be foolish to interpret it any other way so if we do ATOM it should be with this as a goal- The fact that there's even a discussion of using something other than the standard OpenSocial remote API to fulfill the JS API is a shame. This should have been something that drove the specification and not been a case of 'well how do we get this stuff to work together now?' I voted for the spec and so I claim full responsibility for my own frustrations. with that out of the way I'm voting for #2 and heres why... - I think Davids code is very good and having talked to him I don't believe there would be much difficulty in writing a lighter-weight framework in Shindig to replace the Abdera underpinnings of his code and his stuff would continue to run just fine. This is sort of what Cassie attempted it shouldn't be hard to reconcile the non-framework pieces. This is why God invented interfaces :) - It seems like having the lighter-weight Shindig specific framework is really important to folks not working in Java. I think we have enough Java folks that we can eat this cost to make life easier for non-Java folks. - The design patterns represented by Davids code make sense to me and I assume they have served REST implementers well so we should be sure to carry those that makes sense over in any Shindig framework. If #2 is the eventual outcome perhaps David could suggest what he would like to see carried over in the framework?- Adbera may have a place later on if we run into a major blocking issue but it doesn't seem like we are there yet Cheers -Louis On Sun, Jul 13, 2008 at 5:14 AM, Dave <[EMAIL PROTECTED]> wrote: > Cassie wrote: > >> 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) > >> > >> 2. "DataService" (similar to the old wire format GadgetDataServlet) > >> Most code is located in the shindig.social.dataservice package. > > I've got both options working in my project's workspace, so here's my two > cents. > > Option #1 is really "Implementation based on Abdera AtomPub Server > Framework." Initially, I thought this was the best option because the > Abdera server framework takes care of all the little details of > AtomPub compliance, Atom format parsing/generation and it is extremely > pluggable. Plus, Abdera has a fairly active community that is > generally eager to help. > > Option #2 is DataService, which is a "custom REST framework." Though I > initially opposed the idea, I like the option #2 code. It's simple and > gets the job done without the crazy-flexible complexity of the Abdrea > AtomPub server framework. > > But don't forget that the Abdera AtomPub Server Framework is only one > part of Abdera. The core of Abdera is a high-performance Atom format > parser/generator with lots of nice features like incremental parsing, > IRI support, etc. Make sure you take a close look at this option > before you roll your own Atom format parser and generator for option > #2. > > - Dave >
