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

directory/xpcom/TODO.txt

@@ -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 
+* verify that ldap_parse_result() and ldap_get_ldaperrno() aren't
-  Makefile.in?  (maybe should set up MOZ_LDAP_LIBS?)
+  required to be called from the same thread as ldap_result() and
-
+  before the thread-specific ldaperrno has a chance to change.
-* 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.
 
 * 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
+* deal with race condition that happens if data comes back after
-  (eg (sn=Smith) at netcenter) mostly stall out the UI.  moving most of the 
+  nsLDAPChannel::Cancel is called.  AsyncStreamListener expects
-  callback work off the UI thread to the LDAP connection thread didn't 
+  GetStatus to return OK, and asserts when it doesn't.  (blocked waiting
-  help; so this would appear to be lossage in the event system itself.  
+  on insight from Warren about nsSocketTransport's use of mCancelStatus).
-  (blocked waiting on advice/help from event wizards - bug 50104).
 
 * 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.