The key point I would like to make is that XHR is more abstract than what you suggest, and there are use cases that can be solved by creating APIs layered over XHR. In those cases, the layers should be able to define method support applicable at that layer. Secondly, it does not make sense to lump all possible implementations into one class and require all those to be inter-operable. Regards, Subbu On 10/17/06, Mark Baker <distobj@acm.org> wrote: > > On 10/16/06, Robin Berjon <robin.berjon@expway.fr> wrote: > > > > On Oct 14, 2006, at 15:20, Anne van Kesteren wrote: > > > On Fri, 13 Oct 2006 14:18:56 +0200, Robin Berjon > > > <robin.berjon@expway.fr> wrote: > > >> And you guarantee interoperability how? > > > > > > It's not the job of the XMLHttpRequest specification to guarantee > > > interoperability on HTTP level features, imho. Anyway, as > > > indicated, this is likely to be tested in the testsuite. > > > > If you can't guarantee that at least a core set of methods will work, > > the API is simply useless. > > I disagree. > > Common practice with HTTP is what declares what methods are in use at > any given time. As an API to HTTP - which provides portability, not > interoperability - XHR doesn't need to say anything about that. All > it really needs to say about methods in order to remain a good HTTP > API is "SHOULD support other methods", which we've said. > > Anyhow, I think this issue is closed now, right? > > Mark. > > -- ------------------------------ http://www.subbu.org
Received on Tuesday, 17 October 2006 19:47:21 UTC