Paul Sandoz <[EMAIL PROTECTED]> writes:
>
> 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.
This makes sense. I'm as yet not very familiar with the address book
code, so I can't offer more than that.
> 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?
I think I must be missing something obvious: why is the abdirectory:
prefix necessary?
> 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?
Having it work across multiple data sources would be a fine thing.
Presumably RDF data sources could be used for this, and
nsIRDFCompositeDataSource could be used to aggregate them. However,
for this to work, all the data sources would probably need the same
schema (or at least some subset of the schemas would have to be common).
The LDAP RDF datasource that's in the tree is currently just
scaffolding. Peter van der Beken (thanks Peter!) has done a bunch of
work to flesh it out and get it basically working, and I hope to get
this in the tree very soon. Then you'll be able to check out the
existing schema.
> Read only data sources
> Some LDAP sources will be read only, need to be
> able to represent this.
Right, this makes sense. Presumably just requires adding a boolean
attribute to one interface or another.
> 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?
In LDAPv3, at least, the Virtual List View extension is one way to get a
small window into a large query result set. There's an IETF draft on
this somewhere; I got my copy by pulling the OpenLDAP CVS tree and looking
in the docs subdirectory. Caching might make sense, though I don't
know if it's entirely necessary. Ultimately, we probably want to be
able to replicate entire directories (or at least subsets) for offline
use. But that should probably come later.
> 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.
This seems reasonable enough on the surface, but not yet having a good
overview of the addressbook code, I can't guess how much work it might
or might not take. As far as inetOrgPerson <-> vCard mapping, that's
very cool.
Dan
