mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-11-07 12:15:51 +00:00
136 lines
4.5 KiB
Plaintext
136 lines
4.5 KiB
Plaintext
implementation
|
|
--------------
|
|
* finish wiring up the unix build glue into the seamonkey build-glue
|
|
(in progress, dmose)
|
|
|
|
* get the mac build glue wired up, and make the mac build work
|
|
|
|
* get the windows build glue wired up, and make the windows build work
|
|
|
|
housecleaning
|
|
-------------
|
|
* 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]
|
|
|
|
* 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 and fix.
|
|
|
|
* implement nsIPipeObserver 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.
|
|
|
|
* get rid of "friend"liness of nsLDAP{Message,Connection,Operation} classes?
|
|
|
|
* 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). also: does NS_ENSURE_*
|
|
provide adequate error-checking at interface boundaries for JS in
|
|
non-debug builds? should we move away from NS_ENSURE_* as per scc's
|
|
suggestion of just using NS_PRECONDITION, NS_POSTCONDITION,
|
|
NS_ASSERTION? whatever the answers to these questions, 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
|
|
|
|
* finish XPCOMifying nsLDAP{Message,Connection,Operation} and check
|
|
thread-safety in order to allow XPCOM proxies to be used for
|
|
thread-crossing operations (side benefit: also exposes more LDAPy
|
|
goodness to JS)
|
|
|
|
* change timeout value from PRTime to PRIntervalTime (wouldn't require
|
|
LL_* macros).
|
|
|
|
* are we using the right constructs for -lldap40 and -llber40 in
|
|
Makefile.in? (maybe should set up MOZ_LDAP_LIBS?)
|
|
|
|
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
|
|
--------------
|
|
* non-anonymous binding
|
|
|
|
* expose directory entries & attrs via interfaces (cachable?)
|
|
|
|
* nsILDAPURI (see nsIIOService.idl: extractScheme())
|
|
|
|
|
|
perf
|
|
----
|
|
* rather than having one thread per URL, probably should (at least)
|
|
have one thread per LDAP server, perhaps chosen from an already
|
|
spun-up thread pool
|
|
|
|
* 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 unnecessary thread-safety code (NS_IMPL_THREADSAFE) to avoid
|
|
locking overhead
|
|
|
|
|
|
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.
|
|
|