No need to include shindig-dev here explicitly, I think Those of us who are involved with spec decisions are going to be monitoring this list anyway.
+ 1 from me, though I think it might be worth including standardization of app ids in the proposal (using urls as app ids in all cases), even though it's not directly related. 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 > -~----------~----~----~----~------~----~------~--~--- > > -- ~Kevin
