[dev] Crushing temp file generation in Turba Objects

[Michael J Rubinsky]

Quoting Michael M Slusarz <slusarz at horde.org>:

> Quoting Michael J Rubinsky <mrubinsk at horde.org>:
>
>> What I don't understand is why 0b files are being created when the  
>> compose window is created (I see this too).
>
> We are grabbing the full addresslist the first time we open the  
> compose window to determine whether we should output all the  
> addresses to the page or instead use AJAX lookups.  This is why temp  
> file generation only happens once a session for me.

This actually explains an issue I was having with slow compose window  
load times. In this case there is really no reason at all to load the  
*entire* contact - an we need is the email and name fields. Just about  
every contact in my main address book has an image, and this is  
causing all of them to load. Unfortunately, Turba's API doesn't  
currently have a way to limit the fields that are returned. Ideally,  
we should add a $return_fields parameter to contacts/search, but would  
mean that IMP 5.0.15 would require Turba 3.0.10 (or more likely 5.1 /  
3.1 since this is added functionality).

> Maybe we could optimize this with some other API call to Turba,  
> although the flip side is that if we do indeed end up needing the  
> full address list, we already have it and don't need to re-request.

Would IMP ever need the full property list of each contact,  
specifically the binary fields? If not, see above.

> In this situation, I disagree with the statement that the admin is  
> responsible for cleaning up the temp directory.  The problem here is  
> that, with a large installation, the temp directory will fill up  
> almost instantly.

Agreed. I didn't realize the scope of the problem.

> Granted, today's filesystems can probably handle the number of files  
> being created (htrees/btrees help), but it seems like the more  
> appropriate method would be to fix the creation problem.

Agreed. Filtering the fields returned would be a fix to the immediate  
problem (and would reduce memory usage to boot), but the long term and  
more correct solution would be to refactor Horde_Form's image handling  
to either store the tmp file data in the session and unlink them at  
session shutdown, or maybe even store them in Horde's VFS (though that  
would introduce a dependency on the VFS library).

>  As with all things Horde_Form, however, I am of limited usefulness.

I'm right there with you, takes me a considerable amount of time to  
trace through that code :)

-- 
mike

The Horde Project (www.horde.org)
mrubinsk at horde.org