[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>:
>
>> 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).
>
> Guess I'm not seeing the need for the temp data in the first place.   
> If the data already exists in the turba data store somewhere,  
> shouldn't the code be refactored to point to this data instead of  
> creating a copy?

A couple reasons:

(1) Horde_Form_Image usages services/images/view.php to display both  
the current value for the field e.g., the current value for a  
contact's photo, as well as to display the temporary image as it's  
being uploaded/verified/edited. This currently *requires* either a  
file obtained from the VFS or a physical file from the tmp directory.  
The image data from turba is stored in whatever backend the address  
book source uses.

(2) As partially mentioned in (1), Horde_Form_Image both displays the  
current value for the field as well as the uploaded, temporary image  
data during the upload/verify/edit phase.


Granted, these can be worked around, specifically (1) is what I had in  
mind when I spoke of using some type of application callback for  
displaying the image (this might have been in another email).  
images/view.php could call an application method to obtain the image  
data to display, similar to how it currently uses the VFS as a source.  
The problem is that Horde_Form would need to be refactored to allow  
that, and I'm still not sure how that would work with the workflow for  
uploading/verifying/editing/deleting the image since this is *all*  
done via Horde_Form. I don't think we can get around the need for  
*some* sort of session length file persistence. Things like  
editing/resizing/removing the image - with the ability to cancel  
changes after they have been applied (but before committing them to  
the backend) would be very difficult without this in Horde_Form.

These limitations are one of the numerous reasons I broke Ansel away  
from using Horde_Form. It could be refactored to be more like what  
Ansel does with it's image editing code. Not sure how easy this would  
be in the context of Horde_Form_Image since it would rely on a number  
of things external to it (Horde_Image, some image controller scripts,  
view generators etc...). Either way, it's not likely something we can  
do before Horde 5 because changing Horde_Form's behavior in this way  
would be a BC break.

> This is, in essence, what I will be doing to Horde_Mime_Part  
> shortly.  For example: for messages stored on an IMAP server, there  
> is no need for the Horde_Mime_Part to store the contents within  
> itself.  Instead, it should internally contain instructions on HOW  
> to obtain the data, and only grab the data when necessary.  For PGP  
> encrypted parts, this instruction set will simply be a queue of  
> steps needed to transform the data from the base data store.

This is actually similar in principle to what Ansel does when handling  
in-line image editing (cropping/rotating etc...) - Ansel knows where  
it's original image is stored, and it tracks what you want to do with  
it across pages - it's image processing scripts just reapply these  
instructions on the various confirmation pages - only actually saving  
data to storage once the user commits it by hitting Save. The only  
temporary storage that is used is during upload - and this lives only  
during the request since the image is immediately moved to Ansel's VFS  
storage. This is possible because there is no in line editing done in  
Ansel during the upload phase - only after the image is already part  
of a gallery is this allowed (another reason I don't use  
Horde_Form_Image). This is easy for Ansel to do since the image *is*  
the end result and it has control of all the parts/steps involved  
(it's own VFS storage, it's own custom image processing, specialized  
Ansel_Image object, it's dedicated image editing form etc...) Turba's  
use is a little different - the image is just one element of a group  
of properties - and Horde_Form does some voodoo magic with the values  
in the session to handle things that are more difficult because of  
this like e.g., deleting the image from the contact.

All this being said, I do agree Horde_Form's image handling needs to  
be changed - just not before H5.


-- 
mike

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