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 the
IMHO right thing, meaning to support arbitrary methods.
> That should be the responsibility of specifications layered on top of
> XMLHttpRequest. For example, a specification talking about
> XMLHttpRequest for some arbitrary user-agent device might want to say
> that such a device MUST support GET and POST. Another specification
> might require support for some other method.
I have a hard time understanding why that would make a difference. Do
you have a concrete use case where it's harder to implement FOOBAR than
POST?
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 given implementation does not understand/support a particular method - this is correctly addressed by specifying that it should throw a SYNTAX_ERR. But saying anything beyond this would be limiting.
(c) We're considering designing wrapper implementations of XMLHttpRequest (e.g. an implementation of XHR in script wrapping a native XHR object) to solve some use cases related to UI aggregation (e.g. apps aggregating UI components - portlet being an example of a UI component). However, in this case, one of the issues we find is the need to support methods other than GET and POST - there is no semantic mapping of HEAD, OPTIONS etc in this use case, and so a wrapped implementation would not be able to conform to this requirement. I hope this is a concrete-enough example for my argument.
Regards,
Subbu
On 10/11/06, Julian Reschke <[EMAIL PROTECTED]> wrote:
Subbu Allamaraju schrieb:
> 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 the
IMHO right thing, meaning to support arbitrary methods.
> That should be the responsibility of specifications layered on top of
> XMLHttpRequest. For example, a specification talking about
> XMLHttpRequest for some arbitrary user-agent device might want to say
> that such a device MUST support GET and POST. Another specification
> might require support for some other method.
I have a hard time understanding why that would make a difference. Do
you have a concrete use case where it's harder to implement FOOBAR than
POST?
Best regards, Julian
--
------------------------------
http://www.subbu.org
