On 18 July 2016 at 21:53, Evert Pot <evert...@gmail.com> wrote:
> Hi Lukáš,
> A few things:
>
> Did you know you could also just use Sabre\DAV\FS\Directory('ftp://....') ?
> If so, any reason why didn't work?

This does not work as is. The reason is this warning:

PHP Warning:  Sabre\DAV\FS\Directory::getChildren(): stream does not
support seeking in
/tmp/SabreDAV/vendor/sabre/dav/lib/DAV/FS/Directory.php on line 103

This can be solved by wrapping the \FilesystemIterator in \NoRewindIterator.

However, the bigger issue is that it is incredibly ineffective. It's
so slow to a point that it becomes absolutely unusable.

I did a simple test, where I used a directory with 100 small text
files containing "Hello World!". I started up wireshark and started
capturing the FTP packets and tried listing the directory. The
operation takes 90 seconds and 4029 FTP packets are sent. With FTPFS I
get the listing after 20 seconds and 1614 packets. The main problem is
that the ftp:// wrapper creates a new connection for every file. FTPFS
could be even faster, but because the server tends to close the
connection after checking every few files, I added a one-seconds sleep
and reconnect if a function call fails before calling the function
again. With larger number of files (~200) the wrapper version usually
fails with a timeout after several minutes.

There's also a little issue that the ftp:// wrapper requires
allow_url_fopen, which may be disabled by some servers.

> Instead of integrating this into sabre/dav, simply publish it as a separate
> composer package

Does that mean this feature is outside the scope of SabreDAV and as
such, pull request would be rejected?

> Don't use the Sabre/ PHP namespace!

I think if I created a pull request the namespace should be kept as
/Sabre as it would become part of the SabreDAV project. But if the
FTPFS is kept as a separate project, I will definitely change the
namespace to something else.

> As for encryption, it sounds like you are primarily talking about encryption
> on the storage-level, but send back the files unencrypted to the server. Why
> not do this on the Directory/File level? This might be a better place than a
> plugin, no?

Yes, it's on the storage level. It's basically a wrapper (or
decorator, if you want) around the existing File and Directory
implementation. The basic usage is like this:

$root = new \Sabre\DAV\FS\Directory('/webdav/');
$encryptedRoot = new \FSencrypt\Directory($root);

The $encryptedRoot will itself wrap the children in
\FSencrypt\Directory or \FSencrypt\File as needed. Both encrypted
Directory and File handle encryption and decryption of file names and
file data before passing them to a wrapped Directory/File
implementation.

Lukas

-- 
You received this message because you are subscribed to the Google Groups 
"SabreDAV Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sabredav-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sabredav-discuss/CAFa9FQv7rPdK-rvkAUjxyydz6kf%2BertCbxVVyMrwNLZiuJvHyQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to