Paul Sandoz <[EMAIL PROTECTED]> writes:
>
> >> o Organisational LDAP address book. Very simple
> >> implementation since many of the directory
> >> methods do not need to be implemented because
> >> only the query functionality is really used.
> >
> >What are your plans on the preferences front? Our current theory for
> >the preferences changes we need to make to support LDAP autocomplete
> >can be seen at http://www.mozilla.org/mailnews/specs/addressbook/LDAP4.html
> >I assume you'll need more preference changes than just that...
> >
>
> This is good work.
> I like Directory Server Properties Option 3.
Yeah, options 2 and 3 both look good to me. Srilatha, which one are
you implementing?
> I am unsure of the relationship between account
> specific LDAP directories and the address book
> since currently the address is related to global
> address books obtained from the pref.js
At this moment, there is no particular relationship. But presumably
your work will change that. :-)
> Can global LDAP directories be created from the
> File->New menu on the address book i.e. an
> option for File->New->Directory...
That sounds reasonable to me. Perhaps jglick can comment on this, if
she's got an opinion here.
> If a global directory is modified/created/deleted
> from the preferences then the address book needs
> to be notified so that it can update its Address
> Books Pane and Sidebar contents, and vice versa
> if preferences in non-modal.
>
> The address book entries in the prefs.js are
> obtained by using some rather baroque code:
>
> nsDirPrefs.cpp
> nsDirPrefs.h
>
> which uses the nsIPref service. This code is
> specific to the address book and is a hangover
> from the 4.x days.
>
> An address book is represented as a structure rather
> than a collection of property names and values
> (property bag) meaning that it is difficult to extend.
> Ideally for the creation of an address book from
> the preferences we would like to pass a property bag
> of all the preferences directly to the directory
> factory but we currently have to translate values.
>
> My opinion is that this code should be rewritten
> (and ensure that it is account aware), but i don't
> think we have time. Thus we need to modify it so
> that the prefs.js structure supports the required
> attributes that are being defined for the ldap
> directories.
> I think that the only outstanding property name is
> 'uri'.
This stuff is pretty much outside of my experience, but perhaps
Srilatha has some comments here.
> Ideally i think that all address book/directory
> operations should be performed on the 'abbsdirectory'
> RDF data resource, i.e. the boot strap resource (not
> a good name i know).
We're trying to name new mozilla-internal URI schemes starting with
moz- now, as documented in bug 69513. So as per your subsequent post,
perhaps moz-abdirectory: ?
> The global address book container could be represented
> as:
> abbsdirectory://
>
> An account specific address book container could be
> represented as:
>
> abbsdirectory://MailAccount1
>
> This data resource is responsible for creating/deleting
> and instantiating address books from the prefs.js
> for global or account address books.
> Thus clients can listen for changes on the resource and
> the RDF directory data source can easily be used in
> aggregation, for example in a mail news pane.
OK, that makes some sense. Note that you don't necessarily need to
use RDF to get be able to wait for notifications about things
happening -- alternately, you could use nsIObserver and friends. I'm
just thinking out loud here -- there's not necessarily anything wrong
with using RDF for this.
> The mail news preferences can also use this
> data resource and directory resource and filter
> on the child type RDF property value for 'ldap'
Yeah, that would work.
> Alternatively this could be represented in the
> RDF data resource uri as:
>
> abbsdirectory://?type=ldap
Or that. Though I guess I might slightly favor the former.
Dan
--
