Paul Sandoz <[EMAIL PROTECTED]> writes:
>
> Wanted to run by some things i think are required
> for the Mozilla address book to cater for organisational
> (LDAP) and '10K' address books i.e. address books
> with so many cards it is not feasible to list all cards.
>
> o Need attribute that defines if an address book
> is only searchable. This will define organisational
> address books.
>
> - For 10k address books i think the user needs to
> define this via a preference which states that
> the address book should only be searched.
Makes sense.
> - Is an attribute needed to define type so that
> associated icons may be displayed?
Type of addressbook? Or type of card?
> o GUI Search functionality like netscape 4.X and
> the proposed search functionality that was
> described by Josh Harding and suggested by
> Matthew Thomas.
<[EMAIL PROTECTED]">news://news.mozilla.org/[EMAIL PROTECTED]> is
what I assume you're referring to.
I agree; this seems like a nice GUI.
> When a searchable address book is selected
> the 'search bar' should be displayed.
I'm not quite sure what you mean by this.
> o The RDF directory data source needs a query
> command that takes as an argument the search
> critera defined as a boolean expression tree.
>
> - The data source will be responsible for
> for passing the search arguments to the query
> interface on the RDF directory resource conponent
> and listening to the results which are then
> asserted. Thus it is asynchronous in operation.
So if I understand you correctly, this is really an optimization: that
is, a generic helper class could do the entire boolean expression
processing on _any_ RDF datasource. But this allows datasources which
understand expressions themselves (eg LDAP) to do it much quicker.
Right?
> The query command should unassert previously
> returned cards.
Why is this necessary? Won't the newly created listener not know
about any previously returned cards?
> - A general linear search query component is
> available for directories that do not support
> the query interface. This means that existing
> local address books may also be searched.
If this only exists to deal with the exist local addressbook, wouldn't
it make more sense to simply write an instance of the query interface
for the local addressbook that does more clever stuff with
datastructures in order to avoid doing a linear search? Note that I'm
completely naive about how mork & the local address book work, so this
may not be practical.
> o Offline mode. For organisational address books
> it should be possible to create a local address
> book and copy the cards obtained from the search
> criteria. I don't think a local address book
> needs to be created or modified every time a
> search is performed like 4.X functionality,
> but i am not sure how offline works in general.
I _think_ these were two separate features in 4.x: persistent queries
and replicating addressbooks locally. I'm not positive about this
though, perhaps someone who knows for sure can pipe up...
> I think we have moved significantly forward to
> enable the functionality to support this behaviour.
> The only area I am unsure about is the GUI bit.
Yeah; I think things are definitely going in the right direction!
What specifically about the GUI are you unsure about?
Dan
--
