[dev] Crushing temp file generation in Turba Objects

[Michael J Rubinsky]

Quoting Michael J Rubinsky <mrubinsk at horde.org>:

> 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).

I've added this functionality to contacts/search and pass the  
appropriate parameters from IMP_Compose::getAddressList. Since it's a  
new, optional parameter to contacts/search there is no increase the  
required version of Turba. This gets rid of the largest source of the  
tmp file generation. We still have the files created when viewing the  
contact directly in Turba (or any other place we use Horde_Form_Image  
for that matter). These will be (partially) taken care of by the  
change described below.

...

> 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).


I've also added new functionality to Horde::getTmpFile that allows a  
file to be registered for removal at session end, instead of at  
request shutdown. This will probably only work when the user actually  
logs out, but it's better than nothing at this point. There seems to  
be no reliable way of persisting a file for only the session, while  
ensuring it is gc'd without any administrator action AND without the  
possibility of killing an active session's files (as would be the case  
if we ran a timed script to gc the files).

This will have to be fixed, probably in H5, by some combination of  
using VFS to store the image files and some callback function in the  
applications for outputting the images (instead of relying only on  
services/images/view.php).


-- 
mike

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