This removes all call-sites I can currently fix. Tomorrow I'll try to get someone to checkin my changes to security/ and I'll get some help with the Netscape side of things.
nsString::GetUnicode()'s final death-blow will be dealt soon. Please keep this in mind as you add new code :-)
Changes allow us to have a finer control over which parts of the tree are built with PIC. Part of the static build branch landing.
Bug #46775 r=mcafee a=leaf
"On <date & time>, <author> wrote:"
For now, this is optional (set mailnews.reply_header_type to '2' in prefs.js), we will default to only show "<author> wrote:", as usual. This is due to some l10n issues which are part of bug 75377. The date&time format is hard-coded to be en-US if set, again, bug 75377.
bug 23615. r=disttsc@bart.nl, sr=sspitzer@netscape.com
Fix a bunch of leaks (15 of them) in addressbook, addressbook-sync and import-mail code. None of the callers to GetUserProfileDirectory() deallocated their nsFileSpec.
bug 75332. r=chuang@netscape.com, sr=bienvenu@netscape.com
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
