[dev] Crushing temp file generation in Turba Objects

[Jan Schneider]

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

IMP won't require a newer Turba version, as long as the parameter is optional.

>> 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
>
> -- 
> Horde developers mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org


Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/