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 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.
Of course it's limiting, but I would say this is on purpose.
Sorry - I don't follow. A little explaining would help. What purpose other than specifying the semantics of the fields/operations of XHR?
> (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
HEAD ist the same as GET, expect that there is no response body. If you
can do GET, you can do HEAD.
I understand. The issue we have in the use case I listed is that there is no mapping for other options to the programming model exposed to the component developers.
> implementation would not be able to conform to this requirement. I
hope this is a concrete-enough example for my argument.
I'm not sure I follow. XHR is a component that enables user agents to do
HTTP. I can see why a *server* wouldn't implement DELETE (for instance),
but why that component?
In other words, in order to comply to the requirement to support, say, DELETE, we will have to come up with what it means for the component. I could see some use cases, but coming back to the original question, the wrapped implementation should be able to choose the method support depending on what makes sense.
Two sum up, there does not seem to be any reason other than some intent of making implementations support a base set of methods. If the WG feels strongly about this, instead of saying a MUST or SHOULD, the spec could add a statement "encouraging" implementations support these base set of methods.
Regards,
Subbu
Best regards, Julian
--
------------------------------
http://www.subbu.org
