pjs/directory/xpcom/TODO.txt

housecleaning
------------- 
* 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.
  
* some (many?) destructors don't clean up completely or correctly.  
  audit for this and fix.

* many of the instance vars in the various class are probably not 
  initialized correctly.  audit for this (especially member
  initializers, which may have the potential to break XPCOM compliance
  on errors) and fix.

* implement nsIPipeObserver in nsLDAPChannel in case pipe fills up?

* audit for and implement any appropriate NOT_IMPLEMENTED functions

* audit for and fix leaks

* use bloat tools to ensure code is not doing anything dumb

* 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?

* 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)?

* 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.

* revamp nsILDAPService to manage LDAP connections and allow for
  sharing connections between browser clients.

* grep for XXXs and fix the issues 

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 for more event love from blizzard and dougt.

* 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).

* 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).

* 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()).

* 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).


misc
----
* i18n / l10n (any text strings)

* implement progress info interfaces, if possible (% done)

* cachability of nsILDAPChannel content: browser cache? ldap_memcache? both?

* use a rebind_proc?

* HTMLize nsLDAPChannel output for linkification


rdf datasource (in progress: dmose)
--------------
  * non-anonymous binding

  * expose directory entries & attrs via interfaces (cachable?) 

  * nsILDAPURL (see nsIIOService.idl: extractScheme())

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 identical
  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
-----
* get rid of inappropriate use of nsVoidKey by implementing an nsPRInt32Key
* get rid of "friend"liness of nsLDAP{Message,Connection,Operation} classes?
* 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.