Mark Baker [EMAIL PROTECTED]
On 5/17/06, Jim Ley [EMAIL PROTECTED] wrote:
The answer is surely nothing in respect to any of those things, there is
no
reason why cancelling a single request should have any effect on things
which persists beyond a single request.
I agree, but I'm interested in
On 5/15/06, Anne van Kesteren [EMAIL PROTECTED] wrote:
On Mon, 15 May 2006 22:50:52 +0200, Mark Baker [EMAIL PROTECTED] wrote:
I think we could be more specific about what reset the object means,
That's defined in the definition section. In theory it's also linked, but
I'm not sure if that
On 5/14/06, Jim Ley [EMAIL PROTECTED] wrote:
Ian Hickson [EMAIL PROTECTED]
Do we really want to define in that level of detail?
No.
+1
When invoked, this method MUST cancel any network activity for which
the object is responsible and reset the object.
That's fine.
And more than
On Wed, 26 Apr 2006 16:22:49 +0200, Ian Hickson [EMAIL PROTECTED] wrote:
This has been asked a couple of times before. At some point reset will
be defined and it will say that all members of the object are set to
their initial value (as if you create a new instance of the object yes,
I
On Sun, 14 May 2006, Anne van Kesteren wrote:
On Wed, 26 Apr 2006 16:22:49 +0200, Ian Hickson [EMAIL PROTECTED] wrote:
This has been asked a couple of times before. At some point reset will
be defined and it will say that all members of the object are set to
their initial value (as if
On Sun, 14 May 2006 14:00:08 +0200, Ian Hickson [EMAIL PROTECTED] wrote:
Currently it says:
When invoked, this method MUST cancel any network activity for which
the object is responsible and reset the object.
That's fine.
Ok!
--
Anne van Kesteren
http://annevankesteren.nl/
Jonas Sicking [EMAIL PROTECTED]
In IE you can at least test for .status == 200 to test if things worked
out ok. Even though the statuscode for various errors seem to be weird to
say the least, at least they are different from the success codes.
I actually think this is how we should do
If we do go to state 4 then things will look almost exactly like a
successful response. The only difference is that .responseXML will be
null, but that is already the case for a lot of consumers that send
non-xml data.
I'd sort of disagree, the problem will manifest itself by the result not
Jonas Sicking [EMAIL PROTECTED]
The problem is that many formats can't detect that they have been cut off.
Even for something as strict as XML you could be loosing comments and PIs
at the end of the document if the transation is terminated. The reason
responseXML would be null in mozilla is
Jim Ley wrote:
Jonas Sicking [EMAIL PROTECTED]
In IE you can at least test for .status == 200 to test if things
worked out ok. Even though the statuscode for various errors seem to
be weird to say the least, at least they are different from the
success codes.
I actually think this is how
Christophe Jolif [EMAIL PROTECTED]
Even though you can always imagine to find solution to workaround it. I
think it is a bad idea to go to 4 without having a clear knowledge of what
the status really is (successful or erroneous). Indeed bad or null XML can
be due to a bug on the server, not
Jim Ley wrote:
Christophe Jolif [EMAIL PROTECTED]
Even though you can always imagine to find solution to workaround it.
I think it is a bad idea to go to 4 without having a clear knowledge
of what the status really is (successful or erroneous). Indeed bad or
null XML can be due to a bug on
The problem is that many formats can't detect that they have been cut
off. Even for something as strict as XML you could be loosing comments
and PIs at the end of the document if the transation is terminated.
The reason responseXML would be null in mozilla is that we'd get an
internal
Jonas Sicking [EMAIL PROTECTED]
Why do we need to find a solution for error handling? I thought that
wasn't necessary for version 1.0.
Not having error handling at all will seriously cripple the usefulness of
the spec.
We've survived so far without error handling other than magic (and
On Wed, 05 Apr 2006 22:56:28 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
If that is indeed true we need to fix it I agree. Is there a sensible
value we could set .status to for example?
Lets keep .status an HTTP status code. What about dispatching an abort
event on the object as I
Anne van Kesteren wrote:
On Mon, 03 Apr 2006 18:05:56 +0200, Jim Ley [EMAIL PROTECTED] wrote:
The decision at the f2f was that the going to 4 was relied on by
people, used in situations such as hiding the please wait etc. I
think this should continue to be the resolution.
That doesn't
16 matches
Mail list logo
