I've been looking at the address book code with
respect to how it could be modified to support
multiple data sources, for example LDAP servers
or GNOME Evolution.
Below are some observations. I am new to the
Mozilla way so some may be incorrect...
Paul.
Interfaces
Some interfaces include specifics about databases
and the nsIAddrDatabase interface e.g. nsIAbCard.
Should be possible to refactor these into seperate
abstract and specific such that the latter is only
associated with the local Mozilla address book.
This should make it easier to reuse the same abstract
interfaces for other data sources.
+ existing dependecies related to specific, import and
syncing?, will require minimal change.
Preferences and URI definition
Need schemes/uris for different address data sources
and more saved preferences associated with each
source.
abdirectory:mozilla://abook.mab
abdirectory:ldap://user@host:port/blah
abdirectory:ldap-web-top://user@host:port/blah
abdirectory:evolution://foo/bar
likewise for a card. Each scheme type can define the
way to represent a card.
Therefore can register components with abdirectory
schemes?
Auto-Completion
Need to represent different auto completion impls
with different data source schemes. Currently impl
is OK for local address books but need to use a
server based query mechanism for other data sources.
Should auto-completion work across data source
domains? if so need an auto complete aggregator
perhaps?
Read only data sources
Some LDAP sources will be read only, need to be
able to represent this.
Query only data sources
Some LDAP sources will contain thousands of entries
thus only queries, with a limit on what is returned,
makes sense.
Users need to type in query to view returned list
(similar to auto complete?), like in Netscape 4.x
Need to cache result?
GUI dialogs for various data sources
Different dialogs are required for the different
address book sources that may be created.
Address books panel could then look like:
Personal Address Book
v WebTop Address Books
Friends
Work
Card syntax and semantics
Perhaps it would be better to represent a card
using the vCard syntax and semantics? This
format seems to be more widely used esp. for
transmision over the internet. Recently an
LDAP draft has been updated:
http://www.ietf.org/internet-drafts/draft-royer-vcard-ldap-00.txt
which defines an LDAP schema for representing vCard.
We plan to use this in the web top server for
users' personal cards.
Its also easy to map personal information from the
inetOrgPerson scheme to vCard.
http://docs.iplanet.com/docs/manuals/directory/41/gwcust/dsgwparm.htm#1041350
However this may require many changes to the
existing impl and dependencies of, thus may not
justify the effort.
