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 <[EMAIL PROTECTED]> wrote:
On 10/16/06, Robin Berjon <[EMAIL PROTECTED]> wrote:
>
> On Oct 14, 2006, at 15:20, Anne van Kesteren wrote:
> > On Fri, 13 Oct 2006 14:18:56 +0200, Robin Berjon
> > <[EMAIL PROTECTED]> 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
