I don't have strong opinions about the pure implementation choice, assuming that both implementations can implement the full spec about as easily. I do have a strong bias towards finalizing the discussion and moving forward. I also haven't looked at the code in detail. It appears that one of the choices is significantly easier to deal with right now, but may possibly turn out to be limiting down the line; if so, it could presumably be refactored or replaced at that point. Having running code and working tests right now is worth a LOT, as is the ability to move forward on a unified code base for now.
Louis also brought up a couple of spec issues in his opinion below, I think it's useful to address them here but a larger spec discussion should happen on opensocial-and-gadgets-spec: John Panzer (http://abstractioneer.org) On Sun, Jul 13, 2008 at 2:24 PM, Louis Ryan <[EMAIL PROTECTED]> wrote: > 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. It's a little unclear to compare JSON to Atom or AtomPub, as JSON is a data format and AtomPub is a protocol. It's like comparing wheat flour vs. a four course meal: They're at different levels of the stack. That said, I think you're saying that you are hearing that current OpenSocial developers like the JSON format. I think you're also saying that they want a different kind of protocol than the one in the spec. My hope is that most gadget developers won't have to look at the protocol but instead would be using libraries developed by the bleeding edge developers, regardless of the format or protocol chosen. > > - 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. So, again, this is conflating several different things together. AtomPub does not imply multipart batching, nor is it linked to it (in fact it already has read-only batching as a standard format and is easily extensible to update batches). Batching is good. The multipart scheme lets us extend it to many other things (uploading binary data and proxying to third party servers in the middle of a batch to name two), with a trade-off in syntax complexity. Again, my hope is that gadget developers wouldn't be dealing with the protocol syntax directly 90% of the time. > > - 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?' The intent in the spec was indeed that OpenSocial Collections follow AtomPub (RFC 5023) rules, with the additional wrinkle that you can ask for the data in either Atom XML or JSON format. The wording in the spec as it ended up for 0.8 doesn't make this clear and for that I apologize. I'm convinced it was crystal clear earlier, but got edited out :(. Regardless, the spec does reference AtomPub a number of times in specific circumstances, in particular to clarify the semantics of the HTTP operations. So, to be clear, it's all AtomPub in the spec, every collection is an AtomPub collection and every resource is an Atom resource. And, everything is also _equally_ representable as an Atom XML record and a JSON record (the spec adds restrictions on the Atom data to ensure that this is true). BTW, Chris' feeds work great in NetNewsWire :). > > > 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 > > >
