Re: RT::Extension::ExternalStorage

Le 06/09/2015 21:20, Alex Vandiver a écrit :
> This sounds like a purely backend changes, yes?  But it's not clear to
> me what problem you are attempting to solve by doing this.  While

I have been asked to perform some adpatations for differents clients :
- file storage (which ExternalStorage does perfectly)
- inserting Articles files into ticket responses,
- check and limit attachments sizes (client and server),
- create a CF which proposes to pick up a file in a list (files are 
stored server side),
- ...

Each of those developpment could be made separatly, but I began to see a 
picture while coding this : RT could have a way to manage files, server 
side. And once you have this object, every developpment above become 
quite easy to write and without edge effect.

So it's not only a purely backend change, it's about adding a new object 
to RT, which could use the backends method you add in ExternalStorage 
for example.

> unifying the OCFV and Attachment data storage is a perhaps-useful
> goal, I don't see much actual gain from it -- it will increase the
> size of the Links table by orders of magnitude.  I also don't
Gains :
- every developpment about files and attachment is made in the same 
place (this is relevant for me at least ! :) )
- there is a table of uploaded files (and files needed by the server) so 
you have a clear and instant view of this part of your IS;
- I can create a lot of usefull (to me !) features, such as CF with a 
list of files,
- you can link files to *every* object in RT, thanks to the Link table, 
without having to create specific CF or attribute.

The size of the link table is a good point, but will stay very (*very*) 
smaller than group membership for instance.

 > understand how this would avoid having to load the file data into
 > memory when saving or loading (your point 2).

I have overloaded Interface/Web.pm to process attachment directly on 
disk : this way the uploaded files (their content) is never seen by 
Perl. In the same spirit, I replaced in the MimeEntities the "Content" 
attribute by a "Path" attribute.

When loading, I re-wrote some handlers and some classes to "spew" (I use 
Path::Tiny :) ) the file content without loading it in a variable. There 
are still some cases where I need the content, but not much.


-- 
Easter-eggs                              Spécialiste GNU/Linux
44-46 rue de l'Ouest  -  75014 Paris  -  France -  Métro Gaité
Phone: +33 (0) 1 43 35 00 37    -   Fax: +33 (0) 1 43 35 00 76
[email protected]     -   http://www.easter-eggs.com