implementation -------------- * get the windows build glue wired up, and make the windows build work housecleaning ------------- * sort out nsldap.h vs. nsLDAP.h. can the former go away? * why do searches that return lots of entries to the nsLDAPChannel (eg (sn=Smith) at netcenter) mostly stall out the UI? * I have a sneaking suspicion that the thread might be getting killed but not cleaned up when the last nsILDAPConnection::Release is called. But I don't know if that's really the case. Need to check this out. * 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. * remove nsILDAPService from (at least) the build and nsLDAPProtocolModule.cpp (if not CVS), since it's not currently in use. * should nsILDAPOperation subclass nsIRequest? why do some non-nsIChannel things in the mozilla code base implement nsIRequest? * get rid of unixy, non-NSPR/XPCOM includes, functions, and error handling from nsLDAP{Connection,Operation,Message}.[ch] * 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. * come up with a strategy for removing completed nsILDAPOperations from the connection's pending request queue * switch all old-style casts to use either QI or NS_CAST_* macros * 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 (eg nsLDAPChannel::Cancel() and friends) * grep for XXXs and fix the issues * audit for and fix leaks * use bloat tools to ensure code is not doing anything dumb * re-read (esp nsIChannel) idl and make sure all interfaces are implemented correctly * 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). * 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? * get rid of "friend"liness of nsLDAP{Message,Connection,Operation} classes? * 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"? * 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. * migrate from "#ifdef DEBUG_dmose PR_fprintf(PR_STDERR)" to a more general logging mechanism (NSPR logging facilities? nsIConsoleService?) * does always using this-> for member vars cause inheritance problems? if so, does it matter in an XPCOM world? * shouldn't be casting results of nsILDAPConnection::GetErrorString to void in ldapSearch * 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. * get rid of inappropriate use of nsVoidKey by implementing an nsPRInt32Key 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()) 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 ----- * referrals * failover * addressbook/mail UI glue * PSM certs from directory glue(?) * secure (& proxied/socksified?) ldap * ldap_io_functions for portability? (wait for new mcs code?) * 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.