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
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
- Split nsISecureSocketInfo into nsISSLSocketControl and nsIChannelSecurityInfo.
- Incorporate lock icon fixes from psm-glue into pipnss code.
- Implement password callback for client auth in pipnss.
- Locallize the lock icon tooltip.
- Lots of code cleanup.
r=javi, jgmyers, sr=ben.
use the status of the last request processed in loading the document to determine
success or failure. That's incorrect. Instead, test to see if the load group is being
canceled. If it is, use that as the status for the entire document. Otherwise, ignore
the status for the last request and instead use the status for the main document
(the default load channel).
this also means making sure the http channel properly sets it's status code in ResponseComplete (r=gagan)
sr=rpotts, r=sspitzer
darin%netscape.com
tao%netscape.com
disttsc%bart.nl
dougt%netscape.com
alecf%netscape.com
bryner%uiuc.edu
gagan%netscape.com
dbaron%fas.harvard.edu
neeti%netscape.com
ccarlen%netscape.com
cls%seawood.org
warren%netscape.com
mscott%netscape.com
morse%netscape.com
blizzard%redhat.com
mstoltz%netscape.com