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
