Revising nsIChannel to allow for overlapped i/o. This consists of three parts:
1. Factoring nsIChannel into a protocol specific part, the nsIChannel, and a socket specific, the nsITransport.
2. Derive the nsIChannel from a nsIRequest.
2. Changes the notification system from necko and the URILoader to pass the nsIRequest interface instead of nsIChannel interface.
This goal stems from wanting to be able to have active AsyncRead and AsyncWrite operations on nsSocketTransport.
This is desired because it would greatly simplify the task of maintaining persistent/reusable socket connections
for FTP, HTTP, and Imap (and potentially other protocols). The problem with the existing nsIChannel interface is
that it does not allow one to selectively suspend just one of the read or write operations while keeping the other active.
r=darin@netscape.comsr=rpotts@netscape.com
you right click on a folder. thanks to sspitzer and bienvenu for good review. Thanks to
david for providing nsMsgFolder::ListDescendents function and all the help.
messages working again (Bugs #68392 and 68371). For imap, if the
AsyncRead on the cache entry returns any kind of error, punt on reading
from the mem cache and hit the network again.
1. Factoring nsIChannel into a protocol specific part, the nsIChannel, and a socket specific, the nsITransport.
2. Derive the nsIChannel from a nsIRequest.
2. Changes the notification system from necko and the URILoader to pass the nsIRequest interface instead of nsIChannel interface.
This goal stems from wanting to be able to have active AsyncRead and AsyncWrite operations on nsSocketTransport.
This is desired because it would greatly simplify the task of maintaining persistent/reusable socket connections
for FTP, HTTP, and Imap (and potentially other protocols). The problem with the existing nsIChannel interface is
that it does not allow one to selectively suspend just one of the read or write operations while keeping the other active.
The full details of the change on written up in the netlib newsgroup.
r=darin@netscape.comsr=rpotts@netscape.com
after the first fetch, we'll possibly get back a RFC822.SIZE which will have the exact size of the total message.
Update the # bytes we need to download to match this new value if appropriate.
sr=bienvenu
clear the waiting for connection info flag if the user cancels out of the authentication dialogs...
set the url can run but busy flag if we are waiting for connection info. This prevents us from trying to
create a raw protocol connection without going through the request over ride info for webmail.
sr=bienvenu
dprice%netscape.com
dougt%netscape.com
racham%netscape.com
disttsc%bart.nl
naving%netscape.com
mscott%netscape.com
sspitzer%netscape.com
bienvenu%netscape.com
bryner%uiuc.edu
gayatrib%netscape.com
darin%netscape.com
mkaply%us.ibm.com
nhotta%netscape.com