Magic-Mirror/gecko-dev
1
0
Fork 0
mirror of https://github.com/mozilla/gecko-dev.git synced 2024-11-30 00:01:50 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Significant updates to the todo list. a=r=(not built).

Browse Source
This commit is contained in:
dmose%mozilla.org 2000-09-29 00:43:22 +00:00
parent 9f53fa4c3a
commit deecc5b1fd
1 changed files with 29 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

56
directory/xpcom/TODO.txt
View File

@ -1,6 +1,16 @@
housecleaning
-------------
* implement nsIPipeObserver in nsLDAPChannel in case pipe fills up?
* searches that return lots of entries to the nsLDAPChannel
(eg (sn=Smith) at netcenter) mostly stall out the UI. moving most of the
callback work off the UI thread to the LDAP connection thread didn't
help; so this is, in part, lossage in the event system itself (bug 50104).
however, there are a couple of optimizations that may be enough to work
around this: only call OnDataAvailable at the end of a directory entry; if
that's not enough, then append all pieces of the directory into a single
string and then do a single Write and OnDataAvailable.
* need to properly abort channel when errors are encountered
mid-flight (ie in the OnLDAP* callbacks)..
* audit for and implement any appropriate NOT_IMPLEMENTED functions
@ -11,13 +21,9 @@ housecleaning
* re-read the IDL for interfaces implemented by nsLDAPChannel.cpp make sure
all interfaces are implemented correctly
* is there any need or use for implementing nsIWebProgress stuff?
* figure out our strategy for LDAPv2 vs. LDAPv3
* the LDAP SDK returns UTF8, but I think nsILDAPChannel is handing it
off to callers as ASCII. How does this all relate to the stated
UTF16 (referred to as UCS2 in Mozilla) policy for Mozilla?
UCS2 policy in Mozilla?
* investigate use of DNS in LDAP sdk. are sync functions used in the
wrong places (eg they end up getting called from Mozilla on the UI thread)?
@ -25,26 +31,28 @@ housecleaning
* investigate the MOZILLA_CLIENT define as used by the SDK. eg do we still
want the reference to "xp_sort.h"?
* are we using the right constructs for -lldap40 and -llber40 in
Makefile.in? (maybe should set up MOZ_LDAP_LIBS?)
* verify that ldap_parse_result() isn't required to be called from the same
thread as ldap_result() and before the threads-specific ldaperrno has a
chance to change.
* verify that ldap_parse_result() and ldap_get_ldaperrno() aren't
required to be called from the same thread as ldap_result() and
before the thread-specific ldaperrno has a chance to change.
* revamp nsILDAPService to manage LDAP connections and allow for
sharing connections between browser clients.
* grep for XXXs and fix the issues
* error handling: sort out what should be NS_ASSERTIONs vs. normal
error conditions (eg network & data errors). should audit interface
boundaries to make sure they do appropriate checking. also,
shouldn't be casting results of nsILDAPConnection::GetErrorString to
void in ldapSearch. (ideally this would use xpidl nsresult decls
(bug 13423), but that's not done yet).
items blocked waiting for other work
------------------------------------
* searches that return lots of entries to the nsLDAPChannel
(eg (sn=Smith) at netcenter) mostly stall out the UI. moving most of the
callback work off the UI thread to the LDAP connection thread didn't
help; so this would appear to be lossage in the event system itself.
(blocked waiting on advice/help from event wizards - bug 50104).
------------------------------------
* deal with race condition that happens if data comes back after
nsLDAPChannel::Cancel is called. AsyncStreamListener expects
GetStatus to return OK, and asserts when it doesn't. (blocked waiting
on insight from Warren about nsSocketTransport's use of mCancelStatus).
* move the ldap_unbind() call out of the nsLDAPConnection destructor,
since nsLDAPConnection will soon go back to being callable from the
@ -64,13 +72,6 @@ items blocked waiting for other work
binding of the IO functions will provide us with some way to pop out
of the select() that's called under ldap_result() ).
* error handling: sort out what should be NS_ASSERTIONs vs. normal
error conditions (eg network & data errors). should audit interface
boundaries to make sure they do appropriate checking. also,
shouldn't be casting results of nsILDAPConnection::GetErrorString to
void in ldapSearch. (blocked in the hopes that 13423 (xpidl nsresult decls)
gets implemented soon).
* currently nsILDAPOperation::SimpleBind is called as though it were
asynchronous (ie from the UI thread), which it mostly is -- the call
to connect() can stall. We could use the ASYNC_CONNECT flag, but it
@ -80,7 +81,6 @@ items blocked waiting for other work
pushed from nsILDAPOperation into nsILDAPConnection and then called
after the thread for the connection is spun up (waiting on help from
the LDAP SDK folks: bug 50074).
misc
----
@ -127,7 +127,7 @@ later
-----
* get rid of inappropriate use of nsVoidKey by implementing an nsPRInt32Key
* get rid of "friend"liness of nsLDAP{Message,Connection,Operation} classes?
* referrals
* handle referrals
* failover
* addressbook/mail UI glue
* PSM certs from directory glue(?)
@ -136,3 +136,5 @@ later
nsprpub build infrastructure. requires work with the LDAP C SDK
owners, and shouldn't this shouldn't happen until after the most
current ldap SDK code lands in mozilla.org anyway.
* figure out our strategy for LDAPv2 vs. LDAPv3. right now, the code just
uses the C SDK's default of always advertising itself as LDAPv2.