Thanks, yep, I missed that. application/http is a bit like finding a valuable heirloom in the attic... These are some of the details that I hope we can work out if everyone is +1 on the overall approach.
(I think that HTTP pipelining is a nonstarter for the reasons you refer to.) On Fri, Mar 28, 2008 at 11:49 AM, James M Snell <[EMAIL PROTECTED]> wrote: > Sorry that this is a bit late, but I've just now been able to get around > to reviewing the document. I notice that you're using my original > proposal for HTTP Batch operations. Note that I have since updated that > proposal [1]. Also, please note that this form of batching is still > controversial. There are folks who believe that HTTP Pipelining is the > right answer but there are enough problems with current tool support for > pipelining that make it an unreliable and inconsistent solution. > > Anyway, this looks like a good start. > > - James > > [1] http://www.snellspace.com/wp/?p=886 > > John Panzer 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 > > >
