d--j/em-ftpd — comment on commit 529081296d1344c7df1947760db59b5394ede6b8
File:  line 0
By d--j:

Yes, it definitely makes the driver more complex this way. But what about a driver that wants to process data as it comes in? E.g. a driver that directly uploads the file to S3 while the user uploads it to the FTP-server. Or one that GZIPs the data on the fly? How about calculating a MD5 or SHA1 hash of the upload while the data comes in? Or a driver that enforces a maximum upload size? There are many possible things a driver could want to do.

I - for example - currently save the upload to a temporary file and then send the path of this file over to a web service to persist the upload (the web service has direct access to the temporary file). So only after the client completely uploaded the file, I start to process it. With files in the gigabytes this can take a minute or two (copying the file to the final destination, calculating a SHA1 hash) FTP clients tend to time out when the server does not respond timely with a "200 OK" message after the file transfer.
Since the web service is old PHP legacy code and I don't trust it to handle large HTTP file uploads, I want to stick to passing along a file path to a temporary file to it. But I do want to do the SHA1 calculation while the file is uploaded in the driver so that the post-processing in the web service becomes lighter and hopefully quicker (and thus the FTP client timeouts happen only with larger files).