Can I have some hints for async operation of the address book?

Andrew Sutherland asutherland at
Wed Jan 19 20:14:12 UTC 2011

On 01/19/2011 09:03 AM, Kent James wrote:
> On 1/19/2011 12:08 AM, Kent James wrote:
>> So presumably I could let that first enumerate return nothing, do my 
>> async work to enumerate the cards, and then when I am done with that 
>> call into the listing view on the right hand side of the address 
>> book, and ask it to display all of the cards that I now can show. 
>> Does that make sense?
> My first test seem to show that this approach work, that is I can load 
> the directory async by calling 
> nsIAbManager.notifyDirectoryItemAdded(directory, card) as the 
> individual cards are loaded async, as a delayed response to a 
> directory GetChildCards request . Does that make sense?

I am speaking with fairly limited knowledge about the address book, but 
I think your earlier proposal of using the first request as a hint and 
then forcing a refresh of the UI may be superior than sending this 
notifications, which, unless there are more notifications that I know 
of, I think intended for actual mutations of the database?

I would double check that the UI logic is actually only adding the card 
you tell it about in this case (O(dom addition)), as opposed to 
triggering a re-scan (assuming you then are maintaining a set of 
in-memory immediately available cards) (O(dom rebuild)).

You may also encounter some performance hits from other logic hanging 
off the item added notification that assumes it will be used for only 
actual changes to the address book.  Specifically, I believe the message 
reader likes to see if the sender of the message gets added to the 
address book, and gloda also tries to do things to keep itself 
up-to-date.  (Gloda of course tries to be good and do the indexing using 
its throttled indexing, but notifying it about 100 cards and it then 
performing 100 indexing tasks which involve database lookups is likely 
to generate some load even if it is smeared over a few seconds.)


More information about the tb-planning mailing list