[TYPO3-dev] Change driver of a FAL file

[bernd wilke]

Am 29.10.14 19:01, schrieb Philipp Gampe:
> Hi Christian,
>
> Christian Opitz wrote:
>
>> I think, a method addFileFromUrl(...) in an interface extending the
>> DriverInterface would be enough: The target storage could then check if
>> the source storage is remote and publicly available. If yes, it would
>> simply tell the target driver to import the file(s) from their public
>> URLs. If not, local copies would be required anyway
>
> IMHO you are thinking too generic and too specific at the same time. In most
> cases drivers are written explicitly for a project.
> Therefore the author know what drivers exists and what is the best way to
> copy between the storages.
> Thus both drivers definitely should know about each other to hand over the
> all required data for a copy operation (which might be done be a dedicated
> service).
> Your idea is a nice default implementation, but image two storages with fast
> interconnects and a much slower webserver running the TYPO3 instance with
> the copy operation. If you want to transfer a large file (e.g. a video) it
> would be senseless to first download it to the webserver, just to upload it
> again to the other remote storage. It would be much better to copy it
> directly. But in order to do this, the receiving storage needs to know which
> storage is the originating storage without parsing some potentially public
> URL. Also the public URL might not be the fastest way to access the file
> internally.

this might be the fastest way to transfer a file, but does the access 
really work? if you have three servers A, B, TYPO3 and there are 
fal-drivers which connect A to TYPO3  and B to TYPO3 you know nothing 
about the connection between A and B. it could be possible that there is 
no connection at all, or only A can access (read _and_ write) B while B 
can't see A, or B can access A via mount, while A can access B only by 
FTP, or ....

You will need very specific transferroutines depending on A _AND_ B, 
which could have nothing to do how TYPO3 accesses A or B.
The only way for sure to transfer a file is the transfer via the TYPO3 
server, as that is the purpose of the fal-driver(s)

> In general, we should use queues for central FAL operations and be default
> run them instantly, but allowing to replace the queue implementation for
> bigger sites. That way, we could delay expensive operation and either run
> them via AJAX or via dedicated services in the background.
> This needs more thoughts, because we would need a placeholder implementation
> for each operation, such that the editor gets feedback about pending actions
> and the current and future state.
> This is AFAIK partially implemented for indexing but I did not take a closer
> look yet.

I would like such a system around filehandling, even for elementary 
BE-operations like showing files and folders (and also for other BE 
functions).
e.g. https://forge.typo3.org/issues/57811 [1]
having ajax-tasks to fetch the information for each folder. the display 
of a full folder might be a lot faster than today, and so you may have 
not all information, which might be displayed later, you may be able to 
navigate, select, or work with a folder entry in other ways.

always waiting until TYPO3 has gathered and displayed all information 
before you can do anything slows down the BE work very much. :(

>
> It would be cool to create a concept to make FAL work nicely with remote
> storage and to make implementing drivers easy, yet allowing to create
> powerful functionality that scales well.
>
> I could organize a room up to 10 people in Bonn if some devs would be
> willing to meet in person. However there is no budget for travel and hotels.
>
> Best regards
>

[1] I don't think that #56746 could solve #57811 at all, as 
fileselection always shows all files and folders instead of the 
file-list module which reduces the entries shown at a time.

bernd
-- 
http://www.pi-phi.de/cheatsheet.html