You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a big refactoring I have in mind which would break backward compatibility. As such this will probably require creating 2 main forks of pyftpdlib, 1.x and 2.x, both of which will have their own doc and GIT branches. I expect there will be a reasonably long period during which I will release 1.x bugfix only releases and implement new features only in the 2.x branch.
Using Tornado as the base IO loop and TCP/SSL transport handler would give us numerous advantages:
PROS
an native async HTTP client: it is a very common use case to want to execute certain commands by making async HTTP requests towards external services, especially on login. Right now, the only way to do this is by using ThreadedFTPServer class, which turns pyftpdlib from an async to a threaded server, losing all scalability advantages
the possibility to use co-routines instead of callbacks: this supposedly gives the user the possibility to customize / override the base implementation more easily.
the possibility to integrate with Twisted or asyncio IO loops
we can get rid of pyftpdlib internal IO loop implementation which despite it is super fast it's one less thing I'll have to maintain
we can get rid of the internal SSL handling and delegate it to Tornado; again, one less thing to maintain
in general, we can "delegate" all connection / transport related issues to the Tornado project, since we no longer have to maintain a "home made" async IO loop, base TCP and SSL transport stuff. We will also get rid of the asyncore / asynchat dependancy which is clunky and outdated.
CONS
tornado IO loop will probably be slower than existent pyftpdlib IO loop, which is very specific to pyftpdlib and has been massively tuned towards performance
tornado IO loop does not support sendfile() integration; this will have to done either by patching Tornado or by providing an upstream PR for the Tornado project (see here).
breakage of backward compatibilty
The text was updated successfully, but these errors were encountered:
This is a big refactoring I have in mind which would break backward compatibility. As such this will probably require creating 2 main forks of pyftpdlib, 1.x and 2.x, both of which will have their own doc and GIT branches. I expect there will be a reasonably long period during which I will release 1.x bugfix only releases and implement new features only in the 2.x branch.
Using Tornado as the base IO loop and TCP/SSL transport handler would give us numerous advantages:
PROS
CONS
The text was updated successfully, but these errors were encountered: