[EMAIL PROTECTED] (Josh Harding) writes:
> 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.
In LDAP, anyway, you can't know this without actually doing a query
and hitting the limit.
> > 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>.
This sounds cool!
> 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?
In LDAP, at least, we probably need to set some minimum limits so that
naive users don't drive the server into the ground with enormous
searches. Perhaps a minimum search term of at least 2 or 3 characters
would be a good such limit.
> [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.
Probably number 4 is the only one that's really workable.
Dan
--
