Hi all,
I only included the parts I replied to in this one.
Am 02.12.2005 01:02, Chris Ricks schrieb:
Sebastian Werner wrote:
Chris Ricks schrieb:
Class.setDefaultFlightMode(mode) - Sets the default "flight" mode,
with 3 possibilities:
1. Requests are issued as they are made and actually executed when
the user calls the appropriate method.
2. Requests are issued one at a time, with subsequent requests
returning an immediate error (similar to one of my favourite UNIX
errors, EWOULDBLOCK).
3. Requests are executed serially, so that requests are put in a
queue and each is executed as the last one completes.
The default for this setting is up for debate.
I vote for 3.
Given that you're the only person to vote thus far, you win!
I overlooked this point in my first mail.
I propose a 4th solution:
4) Execute up to n request simultaneously, queuing all subsequent
requests while the number of simultaneous requests is >= max number of
simultaneous requests.
Example: Max Number of Sim. Requests = 2
// these two will be executed simultaneously
new Class(url1).send(data);
new Class(url2).send(data);
// this one will be queued and executed when one of req. 1 or 2 returns
new Class(url3).send(data);
I think this one won't cause single high-latency requests, which happen
quite often in my experience, to block other requests which execute
normally.
What do you think?
Class.setMaxRequests(count) - Not really required for usage, but
possibly useful for people not wanting to have stupid numbers of
outstanding requests.
Class.setDefaultTimeout(ms) - Set the default timeout for requests.
What "timeout" means here is something I invite suggestions on. The
obvious suggestions are:
1. A timeout occurs when no state transition occurs within ms
milliseconds.
2. A timeout occurs when the state transition from readyState 3
(loading) to readyState 4 (complete) takes longer than ms milliseconds.
By default, the default timeout being 0 (effectively, no timeout) is
something I'm betting most will agree with.
Whats about latency... I don't think that this time is normally 0ms.
This a default timeout seems to be a bit strong for me.
I've miscommunicated my intent here. A timeout of "0" should be seen as
meaning "never timeout". I guess it's semantically equivalent (in the
eyes of some) to saying:
Class.setDefaultTimeout(false);
I think the first would be the better, but we should support different
timeouts then.
My response to Benjamin referred to your thinking here, and I think
you're right. Perhaps a method that allows one to specifically set
timeouts for transitions from one given state to another.
Given that some browsers don't always trigger all states, implementing
this is something that would require care and testing.
I understand your reasoning Sebastian, but I think triggering timeouts
based on XmlHttpRequest's state change would be not only counter
intuitive, but would bind us to the XmlHttpRequest model of issuing HTTP
requests.
I think the class should provide some sort of fallback (using some sort
of iframe) if XmlHttpRequest is not available or not enabled.
If requests would be made with this fallback solution, simulating these
state changes, would become hell to support I think.
I'd say solution 2 (timeout occurs when time from sending request to
completing reuqests takes more than n ms) is more KISS (keep it simple
and stupid) and therefore better.
Thanks for your review! I just hope that the code that I'm working on
> will be of sufficient quality for consideration for inclusion.
Don't bang your head too long on this one ;)
No modesty necessary, when putting so much effort into this one.
Cheers
Benjamin
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Qooxdoo-devel mailing list
Qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
