On Oct 18, 2006, at 12:29 AM, Anne van Kesteren wrote:
On Wed, 18 Oct 2006 04:35:41 +0200, 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
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
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
On Fri, 13 Oct 2006 14:18:56 +0200, Robin Berjon [EMAIL PROTECTED]
wrote:
I actually agree with Mark (earlier on) and Subbu. It's not the job of
the XMLHttpRequest specification to decide which methods have to be
supported. Whatever the implementation cost actually is.
And you guarantee
On Oct 13, 2006, at 01:55, Anne van Kesteren wrote:
I actually agree with Mark (earlier on) and Subbu. It's not the job
of the XMLHttpRequest specification to decide which methods have to
be supported. Whatever the implementation cost actually is.
And you guarantee interoperability how?
Interoperability between?On 10/13/06, Robin Berjon [EMAIL PROTECTED] wrote:
On Oct 13, 2006, at 01:55, Anne van Kesteren wrote: I actually agree with Mark (earlier on) and Subbu. It's not the job of the XMLHttpRequest specification to decide which methods have to be supported. Whatever the
XHR is a client API and, IMO, is primarily concerned with the semantics
of the fields/methods. The method support is dictated by the nature of
the implementation. Interoperability among a class of implementations
(e.g. between various browsers) is sensible, but requiring that ALL
implementations
Anne van Kesteren schrieb:
On Tue, 10 Oct 2006 00:52:50 +0200, Subbu Allamaraju
[EMAIL PROTECTED] wrote:
I find a bit odd for the XMLHttpRequest draft to require all
implementations to support the listed method names. In particular,
what the motivation for the conformance statement -
[...]
I'd like to add that one of the reasons for talking about this at all is
to *prevent* people from only supporting GET/HEAD/POST .-)
Really?
What I'm trying to understand is that why is it the responsibility of
the XMLHttpRequest spec to say that certain specific methods MUST be
supported.
Well, the MUST is so that clients can rely on a certain set of methods
to be supported. The SHOULD is to encourage implementers to do theIMHO right thing, meaning to support arbitrary methods. That should be the responsibility of specifications layered on top of
XMLHttpRequest. For example, a
Subbu Allamaraju schrieb:
Few points -
(a) I don't think the question is whether it is hard to implement a
certain method or not. It certainly is possible to implement. I'm trying
to find the rationale.
(b) IMO, XHR spec is concerned about specifying the semantics of what
happens when a
On 10/11/06, Julian Reschke [EMAIL PROTECTED] wrote:
Subbu Allamaraju schrieb: Few points - (a) I don't think the question is whether it is hard to implement acertain method or not. It certainly is possible to implement. I'm tryingto find the rationale.
(b) IMO, XHR spec is concerned about
Subbu Allamaraju schrieb:
On 10/11/06, *Julian Reschke* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Subbu Allamaraju schrieb:
Few points -
(a) I don't think the question is whether it is hard to implement a
certain method or not. It certainly is possible to
On Tue, 10 Oct 2006 00:52:50 +0200, Subbu Allamaraju
[EMAIL PROTECTED] wrote:
I find a bit odd for the XMLHttpRequest draft to require all
implementations to support the listed method names. In particular,
what the motivation for the conformance statement -
[...]
In recent editor drafts
20 matches
Mail list logo
