1 files changed, 155 insertions, 0 deletions
diff --git a/ldap/xpcom/TODO.txt b/ldap/xpcom/TODO.txt
new file mode 100644
index 000000000..ff70c2bcd
--- /dev/null
+++ b/ldap/xpcom/TODO.txt
@@ -0,0 +1,155 @@
+housecleaning for first 0.x release
+-----------------------------------
+* error handling: sort out what should be NS_ASSERTIONs vs. normal
+  error conditions (eg network & data errors), especially in nsLDAPChannel.  
+  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).  This also requires some 
+  threadsafety work related to the data and interfaces touched by 
+  nsLDAPChannel::Cancel, since these are used in the connection
+  callbacks, and we also need to be able to cancel from the connection 
+  callbacks themselves. 
+
+* audit for and fix leaks / bloat
+
+* destroy connection & thread when done with it; deal with timeouts 
+  (blocked on LDAP C SDK 4.1, in the hopes that the NSPR 
+  binding of the IO functions will provide us with some way to pop out
+  of the select() that's called under ldap_result().  It may not be worth 
+  implementing this until nsLDAPService is resurrected.  If this
+  doesn't work, we may have to give nsLDAPConnection an event queue &
+  loop of its own, instead of using the LDAP C SDK as a vector to get
+  events over there.
+
+items blocked waiting for other work
+------------------------------------ 
+* go through the various options that can be used with the SDK function 
+  ldap_set_options() and decide if and where the various functions should 
+  be used.  This will include memory allocator settings, and possibly 
+  threadsafety callbacks (if necessary).  (blocked waiting on LDAP C
+  SDK 4.1 to land, since it contains NSPR bindings for some of this).
+
+* 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 seems to be lossage in the event system itself (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).
+
+* ensure that multiple calls to Cancel don't do the wrong thing
+
+* move the ldap_unbind() call out of the nsLDAPConnection destructor, 
+  since nsLDAPConnection will soon go back to being callable from the
+  UI thread, and ldap_unbind() is actually synchronous.  additionally,
+  arrange for the connection thread to shutdown.  (waiting for
+  nsILDAPService to be implemented on the theory that nsILDAPService
+  might have it's own thread and it would be reasonable to call
+  ldap_unbind() from that thread).
+
+* 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
+  seems to do weird stuff on Linux, and mcs says it isn't well tested
+  anyway.  At the moment, my feeling is that fixing ASYNC_CONNECT is
+  probably the right thing to do, but the bind could actually be
+  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
+----
+* 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.  Note:
+  now that ldap_parse_result is only called inside the initializer
+  nsLDAPMessage::Init(), this is probably no longer an issue there at
+  least.  Need to confirm.
+
+* replace instances of (obsolete) |static NS_DEFINE_IID| variables
+  with direct calls to NS_GET_IID in the code.
+
+* investigate use of DNS in LDAP sdk.  I think sync functions used in the 
+  wrong places (eg they end up getting called from Mozilla on the UI thread)?
+
+* audit for and implement any appropriate NOT_IMPLEMENTED functions
+
+* re-read the IDL for interfaces implemented by nsLDAPChannel.cpp make sure 
+  all interfaces are implemented correctly
+
+* implement progress info interfaces, if possible (% done)
+
+* investigate the MOZILLA_CLIENT define as used by the SDK. eg do we still
+  want the reference to "xp_sort.h"?
+
+* i18n / l10n (any text strings)
+
+* cachability of nsILDAPChannel content: browser cache? ldap_memcache? both?
+
+* use a rebind_proc?
+
+* HTMLize nsLDAPChannel output for linkification
+* 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
+  UCS2 policy in Mozilla?
+
+* all attributes are assumed to be strings right now.  This probably
+  needs to change: assume all attributes are binary, use some
+  heuristic to figure out if they're a string.  I wonder how
+  ldapsearch does this.
+
+* grep for XXXs and fix the issues 
+
+rdf datasource 
+--------------
+
+* revamp nsILDAPService (currently unused code) to manage LDAP
+  connections and allow for sharing connections between browser
+  clients.  I think this should obviate the need to hold onto the
+  connection with a delegate factory.
+
+* non-anonymous binding (ie nsLDAPURL supports x-bind-name -- I
+  suspect this may come with the LDAP C SDK version after 4.1,
+  though.)
+
+testing
+-------
+* see how the browser copes when it does such a big search that the server 
+  only returns partial results and an error.
+
+perf
+----
+* rather than having one thread per nsILDAPConnection, have multiple
+  nsILDAPConnections share the same thread.  possibly pre-spin up a
+  thread-pool to handle this?
+
+* nsLDAPService: assuming that we do the above and start using
+  nsLDAPService again, need to implement shutdown for nsLDAPService
+  (probably analogous to the way nsSocketTransportService shuts down.
+  but how does nsIShutdownListener fit in here? and CanUnload?)
+
+* remove any unnecessary thread-safety code (NS_IMPL_THREADSAFE) to avoid
+  locking overhead.  need to figure out if everything must be
+  threadsafe or not.
+
+later
+-----
+* rationalize the logging strategy.  right now there is a mix of 
+  PR_LOG/NS{WARNING|ERROR} and nsIConsoleService and non-logging, 
+  as I have been vacillating on how much logging it's really important to have
+  (part of my thought process about the XPCOM-wrapper being part of 
+  Mozilla-as-platform)
+* get rid of inappropriate use of nsVoidKey by implementing an nsPRInt32Key
+* handle referrals
+* failover
+* addressbook/mail UI glue
+* PSM certs from directory glue(?)
+* secure (& proxied/socksified?) ldap
+* make the LDAP C SDK autoconf glue not be a shim and not require
+  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.