On Wed, May 28, 2008 at 1:47 AM, Franck <[EMAIL PROTECTED]> wrote:
>
> A readyState value of 1 will result in *not firing* the callback.
> I'm missing the reason for this (should it not be '>=' ?)
Tobie Langel did a research on this, and the outcome is that even officially
supported browser handle readystates so inconsistently that we believe
readystates below 4 shouldn't even be used. I think the especially
problematic ready state was 1 ("Loading").
2) Ajax.Response objects
> Instead, I envision a *single* Ajax.Response object per Ajax.Request,
> to be updated as many times as necessary while the XHR progresses to
> completion (readyState value).
I know that every JavaScript implementation is single-threaded,
but--theoretically--couldn't this lead to race conditions? (Eg. when
Response instance changes while you're processing it)
But if you spot places where you can reduce processing being done,
optimization patches are always welcome.
3) JSON
> A XHR can result in yielding a Javascript object in two ways :
> - (a) from the X-JSON header
> - (b) from the XHR responseText
>
> These do not appear to be unified in the actual implementation.
They are stored differenly in the transport layer and have different use
cases, therefore the API for accessing those objects isn't unified.
Still, I imagine I would have nothing against being able to access the
X-JSON object via "json" parameter passed to the callbacks if the
responseText was something other than JSON.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~----------~----~----~----~------~----~------~--~---
