interface and implementation of the Unicode Bidi Algorithm, based on IBM's
ICU (International Classes for Unicode), ported to Mozilla's XPCOM/NS/PR
conventions; not part of the build yet
bug 61108, r=ftang@netscape.com, sr=brendan@mozilla.org
make the (Unix) XP locale parse return the XP version
rework the locale string parsing code to handle variable
length language codes
bug 61108, r=ftang@netscape.com, sr=brendan@mozilla.org
we now store both the XP and Unix platform specific local
the the platform locale is under <tag>##PLATFORM
eg: save the XP locale under
NSILOCALE_TIME
and save the platform locale under
NSILOCALE_TIME##PLATFORM
bug 61108, r=ftang@netscape.com, sr=brendan@mozilla.org
we now store both the XP and Unix platform specific local
the the platform locale is under <tag>##PLATFORM
eg: save the XP locale under
NSILOCALE_COLLATE
and save the platform locale under
NSILOCALE_COLLATE##PLATFORM
bug 61108, r=ftang@netscape.com, sr=brendan@mozilla.org
store both the XP and Unix platform specific local
save the platform locale under <tag>##PLATFORM
eg: save the XP locale under
NSILOCALE_COLLATE
and save the platform locale under
NSILOCALE_COLLATE##PLATFORM
bug 61422, r=ftang@netscape.com, sr=brendan@mozilla.org
add 8 additional code points to the cns <=> unicode converter
Note: because this is a generated (optimized) file almost
every line is changed. see bugzilla 61422 for the converter
source file.
bug 61422, r=ftang@netscape.com, sr=brendan@mozilla.org
In the font preference menu only show one plane of a cns font
since it is really just one font split into sub-planes
ie: show cns11643-1 but not both cns11643-1 and cns11643-2.
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
ftang%netscape.com
erik%netscape.com
Peter.VanderBeken%pandora.be
nhotta%netscape.com
disttsc%bart.nl
maolson%earthlink.net
mkaply%us.ibm.com
tao%netscape.com
yokoyama%netscape.com
dprice%netscape.com
dougt%netscape.com
bryner%uiuc.edu