On Mon, 06 Aug 2007 16:27:40 +0200, Stewart Brodie
<[EMAIL PROTECTED]> wrote:
"Anne van Kesteren" <[EMAIL PROTECTED]> wrote:
On Mon, 06 Aug 2007 16:07:16 +0200, Stewart Brodie
<[EMAIL PROTECTED]> wrote:
> I don't think that introducing a new event for each (currently known!)
> response code is a good idea. Use the readystatechange event instead.
It's not about currently known. It's about response codes for which the
XMLHttpRequest object has special behavior. That's a limited range of
response codes (listed in my opening post).
Are you seriously considering special casing each individual response
code as and when a case is made for it being useful for the client?
You're missing that 1xx is not relevant and that 2xx, 304, 4xx (with the
exception of 401) & 5xx are already addressed. However, agreed that in
theory having separate events might not scale very well. (Although it's
not really separate events, all redirects for instance would be grouped
together.)
I think that to do that is just asking for ongoing trouble. Just make it
generic: create a new event if you don't want to re-use the already
overburdened, overloaded and Byzantine readystatechange event. It'll be
easier to implement and forward compatible, so the problem'll be solved
for all time.
That might be another option, yes. Options so far:
1. Single event that is dispatched for redirects, 401 scenario's etc.
that can be cancelled to let the script author handle it.
2. Separate events for redirects and 401.
3. Boolean attribute that you set before sending which indicates
whether to follow redirects and whether to let the user agent
handle 401.
In case of the third option the response would be treated similarly to 200
or 410 and you would use .status to figure stuff out. Something like
client.controlResponse = true. Even in that case I would have 304 still be
handled in its special way I think as its confusing to most authors and
"normalizing" it to 200 makes sense.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
