2000-05-18 12:48:07 +04:00
|
|
|
housecleaning
|
|
|
|
-------------
|
2000-08-05 12:46:57 +04:00
|
|
|
* 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.
|
|
|
|
|
|
|
|
* deal with timeouts
|
|
|
|
|
|
|
|
* come up with a strategy for removing completed nsILDAPOperations from
|
|
|
|
the connection's pending request queue
|
|
|
|
|
2000-07-11 01:17:59 +04:00
|
|
|
* sort out nsldap.h vs. nsLDAP.h. can the former go away?
|
|
|
|
|
2000-07-13 03:08:11 +04:00
|
|
|
* why do searches that return lots of entries to the nsLDAPChannel
|
|
|
|
(eg (sn=Smith) at netcenter) mostly stall out the UI?
|
|
|
|
|
2000-06-29 01:42:15 +04:00
|
|
|
* 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.
|
|
|
|
|
2000-06-28 23:56:08 +04:00
|
|
|
* 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.
|
|
|
|
|
2000-05-18 12:48:07 +04:00
|
|
|
* remove nsILDAPService from (at least) the build and
|
|
|
|
nsLDAPProtocolModule.cpp (if not CVS), since it's not currently in use.
|
2000-05-09 05:09:11 +04:00
|
|
|
|
|
|
|
* 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
|
2000-07-13 03:08:11 +04:00
|
|
|
initialized correctly. audit for this (especially member
|
|
|
|
initializers, which may have the potential to break XPCOM compliance
|
|
|
|
on errors) and fix.
|
2000-05-09 05:09:11 +04:00
|
|
|
|
2000-07-11 01:17:59 +04:00
|
|
|
* implement nsIPipeObserver in nsLDAPChannel in case pipe fills up?
|
2000-05-09 05:09:11 +04:00
|
|
|
|
2000-05-18 12:48:07 +04:00
|
|
|
* audit for and implement any appropriate NOT_IMPLEMENTED functions
|
2000-05-09 05:09:11 +04:00
|
|
|
|
|
|
|
* grep for XXXs and fix the issues
|
|
|
|
|
|
|
|
* audit for and fix leaks
|
|
|
|
|
|
|
|
* use bloat tools to ensure code is not doing anything dumb
|
|
|
|
|
2000-08-08 07:23:05 +04:00
|
|
|
* re-read the IDL for interfaces implemented by nsLDAPChannel.cpp make sure
|
|
|
|
all interfaces are implemented correctly
|
2000-05-09 05:09:11 +04:00
|
|
|
|
|
|
|
* 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
|
2000-06-28 23:02:27 +04:00
|
|
|
off to callers as ASCII. How does this all relate to the stated
|
|
|
|
UTF16 (referred to as UCS2 in Mozilla) policy for Mozilla?
|
2000-05-09 05:09:11 +04:00
|
|
|
|
|
|
|
* get rid of "friend"liness of nsLDAP{Message,Connection,Operation} classes?
|
|
|
|
|
2000-06-28 23:02:27 +04:00
|
|
|
* 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)?
|
|
|
|
|
2000-05-10 04:07:22 +04:00
|
|
|
* investigate the MOZILLA_CLIENT define as used by the SDK. eg do we still
|
|
|
|
want the reference to "xp_sort.h"?
|
2000-05-09 05:09:11 +04:00
|
|
|
|
2000-05-18 12:48:07 +04:00
|
|
|
* error handling: sort out what should be NS_ASSERTIONs vs. normal
|
2000-06-28 23:56:08 +04:00
|
|
|
error conditions (eg network & data errors). should audit interface
|
|
|
|
boundaries to make sure they do appropriate checking.
|
2000-05-18 12:48:07 +04:00
|
|
|
|
2000-05-18 02:48:50 +04:00
|
|
|
* 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
|
|
|
|
|
2000-05-31 02:12:25 +04:00
|
|
|
* are we using the right constructs for -lldap40 and -llber40 in
|
|
|
|
Makefile.in? (maybe should set up MOZ_LDAP_LIBS?)
|
2000-05-18 12:50:50 +04:00
|
|
|
|
2000-06-28 23:02:27 +04:00
|
|
|
* 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.
|
|
|
|
|
2000-07-13 03:08:11 +04:00
|
|
|
* get rid of inappropriate use of nsVoidKey by implementing an nsPRInt32Key
|
|
|
|
|
2000-05-18 12:48:07 +04:00
|
|
|
misc
|
|
|
|
----
|
|
|
|
* i18n / l10n (any text strings)
|
|
|
|
|
|
|
|
* implement progress info interfaces, if possible (% done)
|
2000-05-10 04:08:26 +04:00
|
|
|
|
2000-05-18 12:48:07 +04:00
|
|
|
* cachability of nsILDAPChannel content: browser cache? ldap_memcache? both?
|
2000-05-09 05:09:11 +04:00
|
|
|
|
|
|
|
* use a rebind_proc?
|
|
|
|
|
|
|
|
* HTMLize nsLDAPChannel output for linkification
|
|
|
|
|
2000-05-18 12:50:50 +04:00
|
|
|
|
2000-06-28 23:56:08 +04:00
|
|
|
rdf datasource (in progress: dmose)
|
2000-05-18 12:50:50 +04:00
|
|
|
--------------
|
|
|
|
* non-anonymous binding
|
|
|
|
|
2000-05-09 05:09:11 +04:00
|
|
|
* expose directory entries & attrs via interfaces (cachable?)
|
2000-05-18 12:50:50 +04:00
|
|
|
|
2000-06-28 23:02:27 +04:00
|
|
|
* nsILDAPURL (see nsIIOService.idl: extractScheme())
|
2000-05-18 12:50:50 +04:00
|
|
|
|
2000-08-09 03:44:48 +04:00
|
|
|
testing
|
|
|
|
-------
|
|
|
|
* see how the browser copes when it does such a big search that the server
|
|
|
|
only returns partial results and an error.
|
2000-05-09 05:09:11 +04:00
|
|
|
|
2000-05-18 12:48:07 +04:00
|
|
|
perf
|
|
|
|
----
|
2000-06-28 23:02:27 +04:00
|
|
|
|
|
|
|
* rather than having one thread per nsILDAPConnection, have identical
|
|
|
|
nsILDAPConnections share the same thread. possibly pre-spin up a
|
|
|
|
thread-pool to handle this?
|
2000-05-09 05:09:11 +04:00
|
|
|
|
2000-05-18 12:48:07 +04:00
|
|
|
* 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?)
|
|
|
|
|
2000-06-28 23:02:27 +04:00
|
|
|
* remove any unnecessary thread-safety code (NS_IMPL_THREADSAFE) to avoid
|
|
|
|
locking overhead. need to figure out if everything must be
|
|
|
|
threadsafe or not.
|
2000-05-18 12:48:07 +04:00
|
|
|
|
|
|
|
later
|
|
|
|
-----
|
2000-05-09 05:09:11 +04:00
|
|
|
* 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?)
|
2000-05-31 02:12:25 +04:00
|
|
|
* 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.
|