- Make the HTTP, FTP and file channels implement nsIPropertyBag2 and associated
interfaces (by inheriting from nsHashPropertyBag)
- Use that interface to expose a "content-length" property giving the length of
the data as a 64-bit value on the FTP and HTTP channels
- change docshell and xpinstall to use nsIPropertyBag2 instead of nsIProperties
to read/write the referrer property
Also changes nsIResumableChannel to have a resumeAt function, that does not open the channel immediately, and changes its size parameter to a 64 bit integer
r=darin sr=bryner
The problem was that InputTestConsumer's QI only listed nsIStreamListener even though
nsIStreamListener inherited from interface nsIRequestObserver.
This adds nsIRequestObserver to the QI.
patch by badami@netscape.com rs=darin a=asa
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
