+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 > > > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups > "OpenSocial and Gadgets Specification Discussion" group. > To post to this group, send email to > [EMAIL PROTECTED] > To unsubscribe from this group, send email to > [EMAIL PROTECTED] > For more options, visit this group at > http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en > -~----------~----~----~----~------~----~------~--~--- > >
