CommandHandler restructure
From DrFTPD
For an alternative implementation, see: CommandHandler_restructure/tds Also see, CommandHandler_restructure/djb61 and CommandHandler_restructure/fr0w
|
About
CommandHandler Restructure slated for 2.1.
There are three tickets #18, #21, and #37 that are contained in the DrFTPD Trac that need more clarification and need to be held in a central location to show their relationshiop.
#21 is the parent ticket, Revised CommandHandler parsing and configuration
Current Design
In 2.0 and 1.1.4, there were two types of CommandHandlers. One type handles commands from the control connection (FTP), the other type handled IRC commands (through the SiteBot plugin). We got into trouble because of duplication of code. There were code segments (that did the same thing to drftpd internally), but had a slightly different way of doing output. As we all know, code duplication causes bugs. There's more code to watch! My solution to this, is to rewrite the way that CommandHandlers are configured and how they interface with their communication layers. The configuration piece should be in one place like commandhandlers.conf.
Zubov's Proposed Solution
The configuration will entail all of the information to be able to run that command. First off, the communication layer to be used. This is essentially a boolean flag, but to allow for more possible methods(and clarity), we can name names.
First
If a line starts with "irc", the command is to be handled with the IRCCommandHandler. If a line starts with "site", the command is to be handled with the SiteCommandHandler.
Right now, site commands are only configured by their name and the appropriate handling class. What I would like to do instead, is use the method that was done for irccommands.conf, which is, to define the name of the "trigger" (CWD, AUTH, USER, etc) and then associate that trigger with a method instead of a class.
Second
Name of trigger, "!bw" or "SITE\ BW"
Third
Name of method. (Needed arguments to be defined by communication layer) (It will need arguments, as the actual CommandHandlers are to be static methods. State information will be held in the CommunicationLayer (BaseFtpConnection) or (Userfile for IRC? Maybe not at all?)
I'll get back to this later, got pulled away at work, to do work, isn't that weird?
