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
add get content listener parent and load cookie attributes to nsIURIContentListener
Bug #21173 --> set the redirected flag on the channel if we are going to redirect the url. Add load cookie
support.
build nsDocLoader in the uriloader.
r=travis
// to distinguish between incoming urls that are a result of user
// clicks vs. normal views, view source and requires new window
nsIURIContentListener.idl--> doContent and canHandleContent now take a nsIURILoadCommand enum
nsURILoader.cpp --> changes to account for load command enum.
AsyncRead pass in the window context as the url context
(waterson will need this for his chrome cache work)
if we can't find a content handler for the content then go
back to the original window that loaded the url and force
them to handle the content...this is a HACK to force us to run
through the old code path for handling unknown content types
until the new version is online.
r=travis
GetProtcocolHandler needs to pass in the uri we are trying to open so the
listener can pick an appropriate p.h. based on the protocol of the uri. (if
they so choose).
Add notion of CanHandleContent. This is supposed to be a light weight method for the implementor
such that the uri loader can ask right off the top if the listener can handle a particular content
type. If it can, then later on, the uir loader may call DoContent to actually handle it.
doContent now returns a boolean called abortProcess. if the listener wants to handle the content without
returning a stream listener, i.e. it wants the uri loader to stop doing anything else with this content,
then it returns true for abort process.
dougt%netscape.com
disttsc%bart.nl
tbogard%aol.net
mscott%netscape.com
dmose%mozilla.org