>> There is already a putback underway that people
>> are working on (Candice, John & Martin have put
>> loads of work in) primarily involved around the
>> refactoring and changes to interfaces.
>
>Any idea how much work is left to go before this gets landed?
>
It has been bounced around a bit because some
bits were failing under certain tests but i
think its nearly all ironed out. I think its
started the super review. John/Candice may be able
to comment more.
>> o Query interfaces
>
>Makes sense. Do you already have a GUI for this up and going?
>
No GUI work has been done yet.
This is the only area i am overly worried about.
I will modify the directory data source this week
so that we can test a simple scenario of search
just for names for example.
>> o Linear Query implementation (currently synchronous)
>> - Slow search a bit like the existing autocompletion
>> for address books that do not support the query
>> interfaces
>
>I think I touched on this in my posting last night, so I won't comment
>more here, other than to say that synchronous stuff running on the UI
>thread probably shouldn't be checked in if we can avoid it.
>
Yes. We will change our existing implementations
to be asynchronous.
>> o Outlook/MAPI address book including query
>> implementation (currently synchronous)
>> - Full outlook address book implementation,
>> (but prob. without listening)
>> Users will be able to enable access to all
>> outlook address books by adding some
>> preferences to the prefs.js file.
>
>Playing nicely with Outlook sounds like a fine thing. I know
>absolutely zero about MAPI and so can't comment much here.
>
Yep. Its really cool!
>> 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.
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
Can global LDAP directories be created from the
File->New menu on the address book i.e. an
option for File->New->Directory...
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'.
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).
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.
The mail news preferences can also use this
data resource and directory resource and filter
on the child type RDF property value for 'ldap'
Alternatively this could be represented in the
RDF data resource uri as:
abbsdirectory://?type=ldap
>> Not all items are complete yet but we are nearly
>> there... and it would be great if we could get this
>> ready/reviewed to go into the code tree before 0.8.1
>> gate closes.
>
>0.8.1 is already out the gate, but with luck we can get some or all of this
>in for 0.9. <http://www.mozilla.org/roadmap.html> has the approximate
>schedule, and the tree closure for 0.9 is April 18th (not far away).
>Getting anything in after tree closure is difficult if not impossible,
>so that's probably the date to target.
>
Oops, meant the 0.9.
I am not sure we are going to get all functionality
in place before the 0.9 gate closes, esp GUI stuff.
>Keep up the good work!
>
Thanks.
Paul.
| ? + ? = To question
----------------\
Paul Sandoz
x19219
+353-1-8199219
