Re: XMLHttpRequest: Why list HTTP method names

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 support these methods would make the specification more
concrete/specific than necessary.

Regarding the use case I brought up, we are considering wrapped
implementations of XHR (e.g. an implementation of XHR in JavaScript wrapping
the native XHR object) to provide some client-side coordination and state
management features. There are two problems that stand in the way -

a. Method support - this is dictated by the programming model exposed to the
component developer. This model currently does not map for methods other
than GET and POST.
b. Semantics on field access - in particular the need to throw
INVALID_STATE_ERR (will start a new thread on that)

I rest my case :)

Regards,
Subbu

On 10/12/06, Robin Berjon <robin.berjon@expway.fr> wrote:
>
> On Oct 11, 2006, at 21:54, Subbu Allamaraju wrote:
> > 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.
>
> I'm sorry but I don't understand your use case at all. Furthermore, I
> don't see how you propose that we produce a specification that
> fosters interoperability by loosening the requirements on its most
> fundamental functionality. My personal opinion on the current draft
> is that we don't mandate enough methods, certainly not that we
> mandate too many.
>
> --
> Robin Berjon
>     Senior Research Scientist
>     Expway, http://expway.com/
>
>
>


-- 
------------------------------
http://www.subbu.org