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 <[EMAIL PROTECTED]> 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
