- From: Bailer, Werner <werner.bailer@joanneum.at>
- Date: Tue, 25 Oct 2011 17:58:07 +0200
- To: "tmichel@w3.org" <tmichel@w3.org>, Yves Lafon <ylafon@w3.org>
- CC: "public-media-annotation@w3.org" <public-media-annotation@w3.org>, Florian Stegmaier <stegmai@dimis.fim.uni-passau.de>
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