60111 - No hidden pref or UI for limiting # of cards in Collected Abook to aid performance

Status: RESOLVED INVALID

(SeaMonkey :: MailNews: Address Book & Contacts, defect, P3)

Description

[esther]

Using trunk builds 11/13/2000 on win98, mac and linux we don't have the hidden
pref to limit the # of cards allowed in the collected abook (still TBD) to avoid
performance problems.  Seth looked in the UI for an alert that would warn the
users if this number was hit, but couldn't find one.

Note: We don't think this is not the same as the Preference item we give the
user to limit the number of cards they collect for reasons other than
performance (i.e. they don't want a lot of cards showing up in autocomplete).

Comment 1

[scottputterman]

I don't understand how this is different than the pref we currently have in the
prefs UI. I don't think we'd want to put up a warning every time they reached
their limit.

Comment 2

[jglick]

I'm also not clear on why this is different than the current UI pref.

Comment 3

[(not reading, please use [e-mail] instead)]

ok, we current have a pref that the user can set to limit the # of cards in the
CAB. ("mail.collect_email_address_size_limit")

the user can jack that up to 10,000.  Then when compose slows down to a crawl
(because of autocomplete, they have no idea.)

I propose this:

I think we also need two new hidden prefs

"mail.collect_warn_limit" default to n (where n is a number we determine on the
target machine and n is greater than the default value for
"mail.collect_email_address_size_limit")

"mail.collect_warned_user" defaulted to false

the first time (we know because "mail.collect_warned_user" == false) the user
jacks up the "mail.collect_email_address_size_limit" pref greater than the
"mail.collect_warn_limit" pref, we put up an alert that says:

"Warning, setting this pref to a large value can slow down compose performance
because..."

and then we set "mail.collect_warned_user" to true, and never warn them again.

there would not be any pref UI for these two new hidden prefs, but we would have
UI for the alert.

Comment 4

[jglick]

What about we just don't let the user set the CAB to a number higher than X? 
(where X is a reasonable value we determine).  When they try and enter a number 
>X, we show a dialog, "The maximum number of entries the Collected Address Book 
can hold is X." User clicks OK and we enter X into the field. 

Users expect the system will make the correct decisions for them. When they get 
warning/info dialogs that they don't understand, they just click OK and "make it 
go away" out of habit. 

If desirable, we could have a hidden pref that would let advanced users raise 
this limit.

Comment 5

[(not reading, please use [e-mail] instead)]

jglick:  I like your solution much better.

have a hidden pref for the max (that power users can change)
and if they try to set the other pref > than the max, we alert.

can you add that to the spec?

Comment 6

[jglick]

will do.

Comment 7

[scottputterman]

another thing we could is put some description next to the pref explaining why
someone might want to change it and what the side effects of changing it are.

Comment 8

[scottputterman]

reassigning to chuang.

Comment 9

[selmer (gone)]

Instead of preventing the user from increasing the limit, what about warning
them about the consequence when they do it?  Something like if newval > X then
warn "some msg".

Comment 10

[(not reading, please use [e-mail] instead)]

better to rot on my list (or racham's) than rot on chuang's list.

Comment 11

[Jeff Hooker]

removed tiantian from cc (bad alias; sends mail to jhooker)

Comment 12

[(not reading, please use [e-mail] instead)]

the CAB doesn't work like this anymore.

http://www.mozilla.org/mailnews/arch/cab.html