88905 - move sync interface to LDAP operations into LDAP XPCOM SDK

Status: NEW

(Directory :: LDAP XPCOM SDK, defect, P4)

Description

[Mitesh Shah]

Need a Sync interface to LDAP through XPCOM, there is one available through 
c-sdk. This is needed for AutoConfig module.

Comment 1

[Jussi-Pekka Mantere]

Setting P4, Future.

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

If moving this into the LDAP XPCOM SDK is the right thing to do, most of the
code has already been written and is in the patch in bug 89137, I believe.  That
code would presumably need to be changed to use nested event queues so that it
could run (eg) on the main thread, and I've heard unhappy things said about
nested event queues in the past.  Any thoughts, leif & blizzard?  (leif for SDK
thoughts; blizzard for event queue).

Comment 3

[Christopher Blizzard (:blizzard)]

Nested event queues aren't terrible.  They just block the layout engine from
reflowing. :)

Do you have to run the UI at the same time?  You might be better off proxying
the updating to another thread and run the UI from the main thread.

Comment 4

[Alec Flett]

well, the point of the synchronous LDAP query is that it does in fact block the
main thread.. the one piece of code that does require this capability runs at
startup, before anything else is loaded, including layout..

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

So what's interesting is that in the specific case of 89137, a nested event
queue is not used because at that time no event queue yet exists on the UI
thread.  However, for most other callers, presumably pushing a new event queue
is exactly what should be done.  It's not clear from the IDL: what are the
semantics of pushing an event queue if no queue already exists on the current
thread?  That is, I suspect the code should be changed to always push if that's
well-defined.

Comment 6

[Alec Flett]

adding danm for event queue questions. I'll bet its ok.

Comment 7

[Dan M]

  Is this the bug I think it is?
  I'm reluctant to teach PushThreadEventQueue to make an initial event queue if
none yet exists for that thread at all. Maybe if Pop...Queue were then bright
enough to not pop it... I suppose that would work. But I'm more inclined to
think that the dopefiend thread should just be properly initialized before
people start stacking event queues on it. Give the poor thing a chance to wake
up before you take it out jogging.
  Is this the bug I think it is? Part of Mitesh's effort to kick off a little
synchronous I/O during application bootstrap, before the main thread's event
queue has been created? How about moving CreateThreadEventQueue earlier?

Comment 8

[Brian Nesse (gone)]

Yes danm, you are correct, this is the thing you and mitesh went round and round
with.

Comment 9

[Dan Mosedale (:dmosedale, :dmose)]

Moving the createThreadEventQueue earlier should work fine.  Note that code
which does this for LDAP autoconfig will be landing soon.  Next time somebody
needs sync LDAP, that code should be generalized and moved into the LDAP XPCOM
SDK and landed as part of this bug.

Comment 10

[Dan Mosedale (:dmosedale, :dmose)]

mozilla/extensions/pref/autoconfig/src/nsLDAPQuery.* is the current home of the
code in question.  Eventually it needs to be generalized and integrated with the
LDAP XPCOM SDK interfaces and code.

Comment 11

[Dan Mosedale (:dmosedale, :dmose)]

Assigning bugs that I'm not actively working on back to nobody; use SearchForThis as a search term if you want to delete all related bugmail at once.

Comment 12

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"