Hi
Thanks for the proposal, this is an area we need to define a good
design to. Currently, as you note, the SITE command is not that very
flexible and would require subclassing/replacement to add in new
commands. No good :-)
As we are moving to the Spring based configuration format, the syntax
you describe below would be different and utilize the Spring beans
syntax. Or, whatever IoC framework you like to use. Or, if embedding,
standard Java code. But, we need to define the interface into which
the user can add his own SITE commands. My suggestion would be to
extend CommandFactory to include methods for registering these. For
example:
/**
* Get the registered SITE commands
* @return Active site commands, the key is
* the site command name, used in FTP
* sessions as SITE <command name>
*/
Map<String, Command> getSiteCommands();
/**
* Register SITE commands. The map can replace or
* append to the default SITE commands provided
* by FtpServer depending on the value of
* [EMAIL PROTECTED] CommandFactory#isUseDefaultSiteCommands()}
* @param siteCommands Active site commands, the key is
* the site command name, used in FTP
* sessions as SITE <command name>. The value is the
* command
*/
void setSiteCommands(Map<String, Command> siteCommands);
/**
* Should custom site commands append to or replace
* the default commands provided by FtpServer?.
* The default is to append
* @return true if custom commands should append to the default,
* false if they should replace
*/
boolean isUseDefaultSiteCommands();
/**
* Should custom site commands append to or replace
* the default commands provided by FtpServer?.
* @param useDefaultSiteCommands true if custom commands should
append to the default,
* false if they should replace
*/
void setUseDefaultSiteCommands(boolean useDefaultSiteCommands);
What do you think?
/niklas
On Sun, Jun 1, 2008 at 11:15 PM, Andy Thomson <[EMAIL PROTECTED]> wrote:
> Proposal to add more flexibility to the SITE command. Attached is the
> proposal details, patches, and user code example.
>
> The change would allow a programmer [user] to add site-specific [SITE]
> commands as mentioned in RFC 959.
>
> The attached example provides a CHMOD command, ie., SITE CHMOD. The code is
> very generic and can be used or adapted to support almost any local OS
> command. A user can for example, add exotic commands such as DUAL for dual
> hashing a file with both MD5 and SHA1 [or whatever algorithms they chose].
> Note: If any one is interested in the DUAL command I will post the code.
>
> The user-SITE "structure" follows the existing ftplet as far as
> configuration.
>
> Here is a snippet from a properties configuration:
>
> ##------------------------------------------------------------------------------
> ## All SITE commands
> ##------------------------------------------------------------------------------
> #config.sitecmds=s1,s2
> config.sitecmds=s1
>
> ##------------------------------------------------------------------------------
> ## Site command s1 configuration, CHMOD a file
> ##------------------------------------------------------------------------------
> config.site.s1.class=org.apache.ftptest.command.SITE_CHMOD
> config.site.s1.cmdname=CHMOD
>
> ##------------------------------------------------------------------------------
> ## Site command s2 configuration, DUAL Hash a file, MD5 and SHA-1
> ##------------------------------------------------------------------------------
> #config.site.s2.class=org.apache.ftptest.command.SITE_DUAL
> #config.site.s2.cmdname=DUAL
>
> Users can call the command using what-ever name or naming style they like.
> The 'cmdname=' just maps the user-supplied name to the command class. The
> example SITE CHMOD could be SITE CHM or any other user-name.
>
> The user must define a command class, this class uses the same structure as
> all of the existing command classes. The class name must start with the key
> characters 'SITE_' followed by some user-descriptive name. In the example
> above, the chmod command class was called SITE_CHMOD. In addition the user
> must extent or modify their FileOject code to allow the FileManager to
> implement the command. The details are provided in the pdf and the example
> code, very easy to do.
>
> The implementation of the SITE change is also easy, only three core classes
> are altered. All of them have additional methods added, and one implements
> the CommandFactory.
>
> Keep in mind there are many ways to achieve this, the code supplied here is
> just one approach.
>
> Comments? Suggestions?
>
> Thank you,
>
> Andy Thomson
>
> ---
>
> Attached is a compressed tar file that contains the proposal details in pdf
> format, patches for the core code, the actual files to the core code, and a
> user example.
>
>
>
>
>
>
