New callbacks in FTPHandler

[GoogleCodeExporter]

Hi, and thanks for the excellent pyftpdlib.

May we have callbacks for the other significant FTP commands. This would let us 
a better and less hacky customization in some situations. In example, I made a 
dirty override of "ftp_RNTO" method in my FTPHandler custom subclass to handle 
file renames.

* def on_rename(self, path):  # Successful rename
* def on_dir_deleted(self, path):  # Successful dir deleted
* def on_file_deleted(self, path):  # Successful file deleted
* ...

Many thanks by advance

Original issue reported on code.google.com by gilles.l...@alterway.fr on 21 Dec 2012 at 2:15

[GoogleCodeExporter]

I always avoided to introduce those kinds of callbacks because the filesystem 
commands are too numerous and introducing a callback for each one of them kind 
of pollutes the API too much.

It is true that the user should be able to easily bind on events such as 
"directory created", "file removed" and such though, so in r1142 I made all 
FTPHandler.ftp_* methods return a meaningful value on success.

This way you can now do:

class CustomHandler(FTPHandler):

    def ftp_MKD(self, path):
        path = FTPHandler.ftp_MKD(self, path)
        if path is not None:
            # a directory was successfully created
            ...

Another possibility to enrich the level of expressiveness would consist in 
introducing a new on_fs_cmd() callback, as such:

    def on_fs_cmd(self, cmd, path):
        """Called when a filesystem-related command (e.g. MKD, RMD, CWD)
        succeeds.

        Most of the times 'path' is the absolute filesystem path we
        just dealt with (e.g. cmd='MKD' and path='/foo/bar').
        In case of RNTO (rename) and SITE CHMOD (change mode) it's a
        tuple.

        Note that this method is called also for RETR, STOR, and STOU
        commands but it doesn't mean the transfer took place (use
        on_file_* callback methods instead).
        """

I'm still not sure whether I really want to add it though (need some time to 
think about it).
Considering r1142 already covers your use case I'd say the possible 
introduction of on_fs_cmd() can be discussed later as a separate issue.

Original comment by g.rodola on 28 Dec 2012 at 2:46

• Changed state: FixedInSVN
• Added labels: Milestone-1.0.0, Version-0.7.0

[GoogleCodeExporter]

Original comment by g.rodola on 28 Dec 2012 at 2:47

• Added labels: API

[GoogleCodeExporter]

That's fine for me. That way my method override will be safer (does not need to 
parse the status code nor the base class privates).

Many thanks for this.

Original comment by gilles.l...@alterway.fr on 28 Dec 2012 at 5:06

[GoogleCodeExporter]

Releasing 1.0.0 just now. Closing.

Original comment by g.rodola on 19 Feb 2013 at 12:49

• Changed state: Fixed