Been thinking about how to improve the preferences
related behaviour/usage of the address book with a
view to rewriting the nsDirPrefs.cpp code.
Still not sure of the best way to ensure that
manipulation of address books and associated
preference properties is consistent and unified.
It is probably not a good idea for the 'abdirectory'
data source to listen for preference changes because
multiple callbacks will be occur for a newly created
address book entry which contains many property entries.
Only solution may be to go through the 'abdirectory'
RDF data resource or data source.
o Should not have to deal with old style preferences
e.g. ldap_1, and perform migrating. This should
be in separate code and run once when required.
o Address book types can be defined by the 'uri'
property.
- Should always be present in the preferences
either as default or in the prefs.js.
- May also result in a reduction in the
number of properties for an address book
depending on what and how much information
the uri can represent.
- Means that properties such as 'type' and
'filename' become redundant.
o For account specific directories there needs to be a
related property that is a reference to the account
in question.
- The property name:
'address.servers.ab5.mail.account'
could have a value of:
'account1'
Thus mail account properties are defined
by appending the property name and value:
'mail.account.account1.*'
o The property name schema for representing address books
could be changed to be more general and meaningful.
- The schema is currently:
'ldap_2.servers.<unique name>.*'
Since there will be address books of different type
the 'ldap_2' could be changed to 'address':
'address.servers.<unique name>.*
- Should the 'ldap_2.servers' be retained for
ldap specific properties and then an address
preference entry could reference a certain
ldap entry?, much in the same manner as an
account specific address book.
o We have modified the nsIAbDirectory.createNewDirectory
to take an array of property names and values which
are strings and wstrings respectively. The 'abdirectory'
implementation is responsible for creating a new entry
in the preferences. The trouble is that type information
is lost because every value is treated as a wstring :-(
- Could do automatic conversion to int and boolean.
I think this could work as long as there are no
complex types, but may not be extensible in the
future.
- Could have method which takes an nsIPrefBranch
attribute which points to the newly created
address book entries.
o The directory factory interface can have an
additional method to create instances from a
branch entry in the preferences using the
nsIPrefBranch interface.
- The nsIPrefBranch.idl has recently been
updated is looking alot cleaner than the
nsIPref.idl
Thanks,
Paul.
