+1 On Tue, Mar 25, 2008 at 2:07 PM, John Panzer <[EMAIL PROTECTED]> wrote:
> *Summary:* > > Do we have a consensus on the broad outlines of the OpenSocial RESTful API > proposal? Please *reply with +1* if you agree with moving forward with > the > current spec (https://docs.google.com/Doc?docid=dc43mmng_2g6k9qzfb&hl=en) > while filling in the details as we build up a reference implementation. I > hope we can declare consensus *by this Friday* at the latest. > > *More details:* > > Most people seem to be generally okay with the proposal. While details > remain to be hammered out, a lot of these are best addressed in > conjunction > with creating a reference implementation. David Primmer volunteered on > shindig-dev to help create a Java reference implementation as part of the > Shindig project, and others have expressed an interest as well. I'd like > to > give them a green light to go ahead on this, and to do that I'd like to > take > a straw poll of the people on this group to see if we have a consensus on > the basic ideas in this proposal. What this means is that you're okay > with > the overall framework, think it's the right time to start a reference > implementation, and the only things remaining to be done are details or > optional parts of the spec. > > *My personal list of current spec issues, from email threads: > * > 1 [EMAIL PROTECTED] Need enum-type field in person example * > Can > we get a good example?* > 2 [EMAIL PROTECTED] Add optional <summary> element in person to > provide for feed reader viewing *Added a note with a placeholder -- how > should a client request such an element?* > 3 [EMAIL PROTECTED] Does application/json content with no type > imply 'text' as in Atom? * Yes.* > 4 [EMAIL PROTECTED] Should escaping of HTML content be part of > the > JSON format spec (matching Atom) or left to the client (more JSON-y)? > *Believe > this should be escaped as is -- based on security discussion on > shindig-dev. > * > 5 [EMAIL PROTECTED] How does AppData JSON represent substucture > *It's turtles all the way down.* > 6 [EMAIL PROTECTED] XML in content needs to carry JSON type > information, JSON true/false/null may need special handling *Query: > Can > lack of a type attribute indicate string type?* > 7 [EMAIL PROTECTED] JSON spec requires double quotes for all strings, > spec should adhere to that *Agreed, looking for a good find & replace > utility.* > 8 [EMAIL PROTECTED] Need a linking structure that doesn't muddy REST > semantics for updates -- collection of data of friends of a user is > immutable, so we need to have implicit or explicit links to an editable > resource. * Agreed, should this be part of discovery?* > 9 [EMAIL PROTECTED] Need to work on url scheme to make resource > identification more deterministic; e.g., we can't use 'self' as a group > name > in /people/{uid}/self vs. /people/{uid}/{groupid} *Suggestion: @self?* > 10 [EMAIL PROTECTED] Use of PUT/DELETE are a non-trivial barrier to > adoption for many developers * Believe this was addressed in email* > 11 [EMAIL PROTECTED] Need to at least be able to specify a > per-container URL prefix (container can pick a "base URL"). *Agreed, > added a placeholder* > 12 [EMAIL PROTECTED] Can we provide batching in a JSON-list manner as > well? E.g., via a single JSON document, specify multiple operations in a > list. *If needed, this could be added as an alternative batch format -- > the logic stays the same. Would like to get more input on cost/benefit > ratio of requiring this.* > 13 [EMAIL PROTECTED] Advise against using URL template rules for > discovering collections (see > http://www.xml.com/pub/a/2005/04/06/restful.html). *Forces all requests > to > go through single domain name. Agreed with the critique, but would like > to have more input on the cost/benefit ratio of adding more complicated > discovery* > > I also welcome co-editors and/or a better way to track and annotate > issues. > We have the existing site, > http://code.google.com/p/opensocial-resources/issues/list, which could be > used to track spec issues, though it's not clear to me exactly how they > could be easily separated from other issues (there are labels, but those > are > applied by project owners at triage time, not at input time). Looking for > input here. > > Thanks, > John >
