AW: follow up on the HTTP status codes for API spec to CR.

Dear Yves, all,

> > Also, in the previous email exchange [1], it was hinted that there was a
> > tunnelling over HTTP in the implementation of this specification, while
> > the specification itself doesn't call for this, so I hope that
> > implementation won't forget the 'Web' aspect while implementing that
> API.

The specification defines the API, i.e., the methods and the return data structure, which can be implemented server-side (and a call to it will most likely involved using HTTP) or on the client side. 
We do think that a client side implementation, e.g. as a JavaScript library, a browser plugin or maybe in future included in a browser, still has a strong "Web aspect", depsite not using HTTP. 

Best regards,
Werner

> -----Ursprüngliche Nachricht-----
> Von: Thierry MICHEL [mailto:tmichel@w3.org]
> Gesendet: Dienstag, 25. Oktober 2011 17:23
> An: Yves Lafon
> Cc: public-media-annotation@w3.org; Florian Stegmaier; Bailer, Werner
> Betreff: Re: follow up on the HTTP status codes for API spec to CR.
> 
> 
> 
> Le 25/10/2011 16:16, Yves Lafon a écrit :
> > On Tue, 18 Oct 2011, Thierry MICHEL wrote:
> >
> >> Yves,
> >>
> >> We have discussed this issue during the MAWG telecon.
> >>
> >>
> >> These status code are not on the HTTP level, but on a layer on top of it.
> >>
> >> As these are on different layers, we have decided to remove the
> >> wording and references to HTTP to avoid any confusion.
> >>
> >> Therefore the "4.7 API Status Codes" section
> >>
> http://www.w3.org/2008/WebVideo/Annotations/drafts/API10/CR/Overvie
> w.html#api-status-codes
> >>
> >>
> >> The section does not mentions HTTP nor refers to it.
> >> The intro paragraph now says:
> >>
> >> [This section introduces a set of status codes for the defined API to
> >> indicate the system behavior. As described in section 4.4, the status
> >> code is returned as one of the attributes of the MediaAnnotation
> >> object returned by a method call to the API. These status codes are
> >> used on the API level, and applied to either client side or server
> >> side implementations.]
> >>
> >>
> >> If you see a coincidence between the Numerical Code and the HTTP staus
> >> code, it is only a coincidence ;-)
> >
> > Well, then why choosing the 2xx 4xx 5xx convention for
> > success/client-side error/server-side errors ?
> 
> as there is already a well know semantic.
> 
> And also if we change these codes now, we should probably go for a third
> Last Call ..., and implementations already use these.
> 
> 
>   As the link to HTTP is
> > removed, it would probably be a good thing to document how to extend
> > those codes. Apart from that, the decoupling changes goes in the right
> > direction, yes.
> 
> OK
> >
> > Also, in the previous email exchange [1], it was hinted that there was a
> > tunnelling over HTTP in the implementation of this specification, while
> > the specification itself doesn't call for this, so I hope that
> > implementation won't forget the 'Web' aspect while implementing that
> API.
> 
> Florian or Werner could you respond to this ?
> 
> 
> > Thanks,
> >
> >
> > [1]
> > http://lists.w3.org/Archives/Public/public-media-
> annotation/2011Oct/0043.html
> >
> >
> >

Received on Tuesday, 25 October 2011 15:58:36 UTC