Paul Sandoz wrote:
>
> 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.
Is it possible to query the AB and see how many records are in there
before attempting to display? If so, how about a pref (defaulting to
10K or whatever) that specifies the MAX_DISPLAY_RECORDS. If the AB has
more than that number of records, it's search-only. This would require
less interaction by the user. They don't have to know to set a specific
AB as search-only... it's done automatically for large ABs, but the
advanced user still has the option of seeing all records if they really
want.
> - Is an attribute needed to define type so that
> associated icons may be displayed?
You mean have a diff icon per AB that indicates if it can be browsed or
just searched?
> 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.
How about this: After a search is completed (regardless of the source),
present the user with the option of merging the results into an existing
AB[1] or adding to a new one:
[Save these search results to] [Personal AB:^]
In the select list, is a list of all local ABs and the keyword <new AB>.
Scenario: User selects and AB with >10K records and gets the search
options. They perform a search for <email> contains "@". Do you stop
the search after MAX_DISPLAY_RECORDS(see above) are found and present a
warning?
[1]: Merging search results could present other problems. What do you
do with duplicate entries? Options:
1) Overwrite the existing entry with the one from the search results.
2) Keep the old one and ignore the new one.
3) Use data from the new one to fill in blank fields from the old.
4) Present the user with a dialog giving them the above options and a
"use this choice for all remaining conflicts".
None of those seem real appealing to me.
The Amigo
