1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
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.
|
