[turba] Performance of turba with very large Address Book

[Oliver Schönrock]

--On 13 September 2002 15:14 -0400 Chuck Hagenbuch <chuck@horde.org> wrote:

> Quoting Oliver Schönrock <oliver@schonrocks.com>:
>
>> - the fact that each record contains not just the data displayed but =
also
>> a fully serialised copy of the Turba_Contact object. This allows
>> multistage searches to include the results from previous searches.
>
> This is not the case in HEAD, though I'm not sure how far back it's been
> merged. Searches are only cached inside the user's session now.

I haven't been looking at HEAD, sorry, obviously I will have to get into 
it. ;-) Nice place for the repeat search info, that's where it belongs.


>
>> - The checkbox selection Javascript is very inefficient for size
>
> Any optimization suggestions?

There would be a couple of options that come to mind:

- If we could assume (dangerous word!) that email address, and maybe real 
name, are always two of the displayed columns, then the "Send Message" 
Javascript could just iterate through the displayed table to construct the 
compose.php query string (or POST data!) at the time of chosing to send the 
mail, rather than building a client side array when the checkboxes are 
toggled. This would avoid the duplication of data in the current HTML.

- alternatively the "Send Message" Javascript could simply open the new 
window (which is the only thing you can't really do serverside) using a 
turba url with a query string to pass the array of "checked" turba_object 
id's (turba_object keys or a page specific id which only indexes into the 
session data). That turba url/script would then use the information that 
you now have stored in the session 'joined' with the 'checked' info to 
construct the imp/compose.php query string (or POST data) and then use a 
redirect to call that script.

I prefer the second option since it keeps the action server side and 
provides a clear turba->imp API interface php-script which could also 
handle any future "parameter passing issues". I am happy to look into 
either of these if it's of interest to others here...once I have updated 
myself on what's happening in HEAD ;-)

On another note, I posted here some time ago, regarding using turba for 
managing large groups. What does the API for passing long lists of 
addresses  to compose.php look like for groups in HEAD? does Turba still 
pass all data or does IMP take the burden of expanding groups. For a 
current client I am integrating with majordomo on 
add/change/delete/object.php in order to sync with a proper mailing list 
for large groups. This means you can then just send a mail to the mailing 
list; ie single turba entry. Much more scalable! But it's a hack at the 
moment using CURL to post updates to a MajorCool interface, because of the 
problem of closing the confirmation loop with email based commands to 
majordomo.

Anyone have any better ideas how to solve this, or alternatively would 
there be interest in having "mailing list drivers" as a standard API to 
Turba considering it now supports groups? Something else I could look 
into...

Cheers

Oliver