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
Mark Baker schrieb:
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
On Oct 17, 2006, at 15:23, Mark Baker wrote:
Common practice with HTTP is what declares what methods are in use at
any given time.
If common practice were enough, the spec in its entirety would be
useless. There's lots of common XHR practice. Besides, the Web's a
big place. A lot of
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 doesnot make sense to lump
On Oct 17, 2006, at 6:23 AM, Mark Baker 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
Maciej,
On 10/17/06, Maciej Stachowiak [EMAIL PROTECTED] wrote:
A minimal set should definitely be stated, otherwise the API spec
doesn't guarantee enough to do anything useful and code will
inevitably depend on implementation conventions. An implementation
that did not support, say, GET or
On Tue, 17 Oct 2006, Mark Baker wrote:
On 10/17/06, Maciej Stachowiak [EMAIL PROTECTED] wrote:
A minimal set should definitely be stated, otherwise the API spec
doesn't guarantee enough to do anything useful and code will
inevitably depend on implementation conventions. An implementation
