You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

Skip to main content

LDAP Replication
notes and task list
last updated (1-17-2002)
Rajiv Dayal, Dan Mosedale and Seth Spitzer

1) LDAP Replication basics

First time you replicate, do a query on the LDAP server, create a MDB addressbook (and the associated .mab file), copy each result from the query (a nsIAbCard) to the newly created MDB addressbook, store the current time with the nsIAbMDBDirectory as the "last replicated time".

Add getter / setter for "last time directory was replicated" to nsIAbDirectory (or nsIAbMDBDirectory)

Next time you replicate, do a query on the LDAP server for "all cards modified since the last replicated time".  For each card, replace the card in the MDB addressbook.

Add UI for "replicate this LDAP ab now"

when online:
  when we autocomplete, we hit the LDAP server.
  when in addressbook, we hit the LDAP server

when offline
  when we autocomplete, we hit the replicated .mab
  when in addressbook, we hit the replicated .mab

When we autocomplete against a LDAP server, we have one algorithm and don't search unless we have a minimum number of chars.  our local addressbook algorithm does a better job at sorting the results by importance, and it doesn't have a minimum char limit.  so autocompleting against a replicated LDAP server will behave differently than against the same LDAP server, when online.

When getting search results back from LDAP replication, we don't have to proxy the search results (or the AB card) over to the UI thread.  (this is costly).  perhaps we can do everything from the LDAP thread, and just proxy across progress?

VLV:  when we add vlv, use it to do replication in chunks.  (can recover from network error, more performant?)

read tcrowe's docs:   http://jazz/users/tcrowe/publish/dsgnrvw.html


2) open issues
  • how do we handle when cards are deleted?
  • how do we find the card X (from a "modified since" query) in the MDB addressbook?
  • didn't 4.x do "change log"?  Why aren't we doing that?  see http://lxr.netscape.com/nova/source/lib/libnet/mkldap.cpp
  • when LCUP becomes a standard, will we be able to convert our code to it?  http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-02.txt
  • make sure for our LDAP queries, max hits is not set.  (we want all hits)
  • what did 4.x do that we aren't doing:   "auto replication before going offline"
  • figure out our replication performance bottlenecks  (hint, fix local .mab performance and this gets faster, too)
  • figure out some performance numbers (based on the size of the LDAP addressbook, how long does initial replication take?  how long do updates take?)
3) people to talk to
  • Todd Crowe (tcrowe@netscape.com)
  • Mark Smith (mcs@netscape.com)
4) future items
  • are there scenarios where we'd want to autocomplete against our .mab instead of ldap?   What we first hit the LDAP server, ask it what's the last modified date, if the same as ours, go local?
  • autocomplete (prefs to skip on a per directory basis)
  • autocomplete (prefs to autocomplete agaist more than one at a time)
5) Tasks
  • come up with a design (rdayal)
  • review the design (dmose, sspitzer)
  • implement (rdayal)