[dev] [cvs] commit: imp/lib Compose.php imp/templates/prefs sourceselect.inc
Chuck Hagenbuch
chuck at horde.org
Fri Jul 25 02:50:29 UTC 2008
Quoting Michael M Slusarz <slusarz at horde.org>:
> Here's my thoughts after sleeping on this:
> 1.) Non-AJAX expansion can only occur if search_fields is equal to
> 'name' and 'email'. Any other search_fields requires AJAX expanstion.
Why not just pull the fields that are set to be searched, either way?
> 2.) Non-AJAX expansion would only occur if a user has below a
> certain threshold of entries in his addressbook (200?). We could do
> this threshold check once per session and use the results for the
> rest of the session (ignoring any adds/deletes from the addressbook
> in that session).
Ignoring adds/deletes during the course of a session seems very
counter-intuitive to me. 200 seems like a reasonable guess at a limit,
though it's worth testing. I assume the issue here is bandwidth, not
the backend search time? In that case the ability to compress the list
(gzip compression) would be very helpful and might get the limit
higher. The list could also be served as a standalone json file with
proper caching headers, to allow not delaying the loading of the
overall compose screen.
> 3.) Looking at scriptaculous' controls.js (the file that contains
> the Autocomplete code), about 60% of that file is dedicated to an
> AJAX in-place editor that we are not using. It is a substantial bit
> of overhead that we don't need, so I think I am going to break out
> the autocomplete code into a separate file. Considering a possible
> future goal is a rewrite of the autocomplete code anyway, this is
> something that would eventually happen anyway.
That seems reasonable to me as long as the rewrite does happen; we
wouldn't want to distribute modified scriptaculous code in any case
(i.e, we shouldn't call either split-out version controls.js, I think).
-chuck
More information about the dev
mailing list