I'm feeling a little lazy and therefore I'm not going to go through all the extremely well thought out discussions on this thread. Instead, I'm going to take the pragmatic approach:
First, there is an existing specification for RESTful APIs in OpenSocial. It requires both AtomPub and JSON bindings. As a reference implementation, Shindig MUST implement both of these correctly. If there are flaws in those specs that make implementing them very difficult, then that's an issue for the spec discussion list. Secondly, this process has been going on for far too long. I've mostly sat out of the development here as the bulk of my time has been taken up on gadget rendering. I never really paid that much attention to how the REST implementation was going initially because I saw lots of check ins and discussions and I assumed that things were going well. It wasn't until the "Abdera isn't working for us" thread that I started paying closer attention to what was going on in that area. We have several talented and capable people working on implementing the social APIs, and I'd hope that we could have come up with a solution without resorting to this kind of debate. We have "customers" who just want something that works. They don't care if we're using Abdera, something custom, or something else. The RESTful spec was published nearly 2 months ago, and we need to get an implemention out there so that all of the containers that are based on Shindig can deploy. There's a pretty good recent analogy for this issue, which was the Linux task scheduler. Two very capable implementations were developed, but the one that was chosen was done so because the people who worked on it were highly dedicated to the task. I think the same criteria needs to be applied here. For people who are in favor of the 'new' code, are you willing to accept the burden of maintenance, patches, and support? Are you going to continue doing that even if you change employers? for people in favor of the abdera code -- I ask the same. That's really what this boils down to. If both implementations get the job done correctly, then the decision for which one to use is simply a matter of determining who's going to ensure success of the component. If we only have one person who's going to work on one side and 10 people on the other, then the choice is obvious. Now, if either implementation isn't implementing the spec correctly, then it's not really qualified to be here given that the entire purpose of Shindig is to have a reference implementation of the OpenSocial standard. Today, that means support for both AtomPub and JSON bindings, whether we like them or not. We can't pick and choose which parts of the spec we want to implement correctly; if something in the spec is painful or bad for other reasons, we need to provide feedback to the spec itself, not bitch amongst ourselves. On Sat, Jul 12, 2008 at 7:16 AM, Chris Chabot <[EMAIL PROTECTED]> wrote: > > On Jul 12, 2008, at 5:49 AM, Joe Gregorio wrote: > > OK, this is something I don't understand and would appreciate help >> understanding. >> I thought OpenSocial was a set of two specifications: a JavaScript API and >> and AtomPub+extentions API that gave non-browser clients access to >> some/all >> of the same data that you could get to via the JS API. >> If that is true: >> > > See the documentation for the RESTful API : > > http://www.opensocial.org/Technical-Resources/opensocial-specification----implementation-version-08/restful-api-specification > > The non-browser facing RESTful service supports both a JSON and an Atom > format, the output is JSON by default, and an Atom response is generated if > ?format=xml is appended to the URL. > > Ideally the implementation of the restful api should be generic enough that > other output formats can be implemented relatively easy, so that when we > decided 'new format Foo' is something we need to support, it could be added > by adding another output format converter. > > Since the JSON REST format is a first class citizen in the social data and > easy to consume by javascript we use it for the gadget/browser based > communications as well, but it's the same interface as the non browser > facing one. > > 1. Why is there any discussion of the "specification" of the JSON >> interface? >> I can see implementing a JSON based back end that the JS API uses >> and "documenting" it, but where does the need to turn that into a >> "specification" >> come from? >> >> 2. Has it been decided that the non JS-API has to be full parity with the >> JS API? If so, does it have to be full parity in the first release, or >> just >> eventually? >> > > See above, they are the same thing > > I responded to this earlier in the thread, either do a full >>> >> implementation or don't >> do them at all. >> > > See i agree with this a 100% in generalistic terms.. the REST interface > will support the get/post/head/delete methods, output atom compliant > messages with all the proper bits in the right places, whichever solution we > pick for actually coding this, that's not what the discussion is about, the > discussion is about which implementation to use to support the Atom & Json > formats. > > Someone mentioned "You need to pick solution <Foo> to support all the > things we want to do with this", but i have not yet gotten any insight into > what those "things" are, nor do i see why a certain problem domain has to be > tied to a specific solution. There are always many solutions to a problem > domains, and there's a lot of different technical implementations of the > Atom spec. > > So no one is saying we shouldn't support the Atom & AtomPub standards as > they exist, I'm merely trying to find out what reasoning there is behind the > "you need to chose <Foo>" to more detailed terms, so we can discuss the > actual merits and downsides of each solution with an appropriate level of > detail, otherwise how can we weigh how much work and what the level risk > with each of the implementations are? > > -- Chris > >
