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
Windows and Mac, and fix a couple nsSpecialSystemDirectory bugs.
All the changes are BeOS specific (i.e. wrapped in XP_BEOS or
only used by code wrapped in XP_BEOS).
r=mcafee
in so many different directories, that I think it's the best way.
I've pulled and clobber_all'd my tree and got
r=dp
on this checkin.
Here are the touched files:
M mozilla/embedding/browser/activex/src/control/MozillaBrowser.cpp
M mozilla/embedding/browser/activex/src/control/MozillaBrowser.h
M mozilla/js/src/xpconnect/shell/xpcshell.cpp
M mozilla/netwerk/protocol/res/src/nsResProtocolHandler.cpp
M mozilla/xpcom/build/nsXPComInit.cpp
M mozilla/xpcom/components/nsComponentManager.cpp
M mozilla/xpcom/components/nsIServiceManager.h
M mozilla/xpcom/components/nsServiceManager.cpp
M mozilla/xpcom/io/nsSpecialSystemDirectory.cpp
M mozilla/xpcom/io/nsSpecialSystemDirectory.h
M mozilla/xpcom/tests/TestBuffers.cpp
M mozilla/xpcom/tests/TestPipes.cpp
M mozilla/xpcom/tests/TestShutdown.cpp
M mozilla/xpcom/tests/windows/TestHelloXPLoop.cpp
M mozilla/xpcom/tools/registry/regExport.cpp
M mozilla/xpcom/tools/registry/regxpcom.cpp
M mozilla/xpinstall/stub/xpistub.cpp
M mozilla/webshell/embed/ActiveX/MozillaBrowser.cpp
M mozilla/webshell/embed/ActiveX/MozillaBrowser.h
M mozilla/webshell/tests/viewer/nsMacMain.cpp
M mozilla/webshell/tests/viewer/nsPhMain.cpp
M mozilla/webshell/tests/viewer/nsWinMain.cpp
M mozilla/webshell/tests/viewer/unix/gtk/nsGtkMain.cpp
M mozilla/xpfe/appshell/src/nsFileLocations.cpp
M mozilla/xpfe/bootstrap/nsAppRunner.cpp
The heart of this checkin is a change in the signature and symantics
of NS_InitXPCOM.
The new signature is
extern NS_COM nsresult
NS_InitXPCOM(nsIServiceManager* *result, nsFileSpec* binDirectory);
I filed a bug for this problem:
b=23157
The original manifestation of this bug was in mozilla/netwerk/protocol/res/src/nsResProtocolHandler.cpp It used the current process directory to find resources, which is not correct when the current process is not mozilla.exe.
I have added a new type to nsSpecialSystemDirectory, Moz_BinDirectory, and made nsResProtocolHandler use that value.
valeski%netscape.com
darin%netscape.com
cls%seawood.org
dougt%netscape.com
disttsc%bart.nl
warren%netscape.com
rayw%netscape.com
mscott%netscape.com
dp%netscape.com
conrad%ingress.com
locka%iol.ie
ruslan%netscape.com
brade%netscape.com
andreas.otte%primus-online.de
slamm%netscape.com
mkaply%us.ibm.com
scc%netscape.com
sdagley%netscape.com
rpotts%netscape.com
sspitzer%netscape.com
duncan%be.com
edburns%acm.org
bryner%uiuc.edu
sfraser%netscape.com