You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Andy Thomson <a1...@gmail.com> on 2008/06/01 23:15:05 UTC
FTPSERVER - Proposal to add additional SITE command functionality
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.
Re: FTPSERVER - Proposal to add additional SITE command functionality
Posted by Andy Thomson <a1...@gmail.com>.
Niklas,
Good catch on this one!
>> The SITE.getCommand() method can look for the
>> requested command in the default map first, if it's not there, it can then
>> search the user map (if one is defined).
>
> Yes, that's exactly how we do it for commands in general, although the
> other way around so that you can replace the default commands.
>
I'll change my code around in the SITE command to read the custom map
first then read the default one. You are correct you want the custom map
first in-case the user has implemented a replacement for one of the
default commands.
Also will re-submit the patches based on the top-level project, just
saves some extra command-line work. I should add some test case(s) too.
Andy Thomson
Re: FTPSERVER - Proposal to add additional SITE command functionality
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Mon, Jun 2, 2008 at 1:36 PM, Andy Thomson <a1...@gmail.com> wrote:
> Hi Niklas,
>
> One of the reasons I left the original SITE command Map in place is because
> I did not want to replace all of those commands, I only wanted to add one or
> two new ones.
Agreed.
> In addition I did not want to pull back the SITE command list,
> build a new Map with the old and new commands,then replace the SITE command
> map. It was easier to just add the setCommand() to the CommandFactory
> interface, and then implement the method in the SITE class.
The way we do the similar thing in DefaultCommandFactory is to use two
separate maps, one for the default commands and one for the custom.
Then, at resolution time we consult them both (if default commands are
to be used). My design above uses the same pattern.
> The SITE.getCommand() method can look for the
> requested command in the default map first, if it's not there, it can then
> search the user map (if one is defined).
Yes, that's exactly how we do it for commands in general, although the
other way around so that you can replace the default commands.
> A method such as isUseDefaultSiteCommands() is a good idea. Maybe just add
> it to the CommandFactory interface?
Yes, that was my thought in the previous mail.
/niklas
Re: FTPSERVER - Proposal to add additional SITE command functionality
Posted by Andy Thomson <a1...@gmail.com>.
Hi Niklas,
One of the reasons I left the original SITE command Map in place is
because I did not want to replace all of those commands, I only wanted
to add one or two new ones. In addition I did not want to pull back the
SITE command list, build a new Map with the old and new commands,then
replace the SITE command map. It was easier to just add the
setCommand() to the CommandFactory interface, and then implement the
method in the SITE class.
I think the user SITE commands should be in-addition to the existing
SITE commands. Think of the existing commands like an embedded ROM chip,
they will always be there, the user-ones may not, and if the user messes
up their side [think of flash], the embedded ones will still be there
and will still work. So I would just treat the existing SITE commands
as the default command map, and then add a user command map only if
there is at least one user SITE command defined. The SITE.getCommand()
method can look for the requested command in the default map first, if
it's not there, it can then search the user map (if one is defined).
A method such as isUseDefaultSiteCommands() is a good idea. Maybe just
add it to the CommandFactory interface? All commands have to use that
interface in any case.
Not sure what impact the above will have on Spring-based configuration
format, have to investigate it. On the surface it appears there will not
be any issues [hopefully not famous last words].
Andy Thomson
Niklas Gustavsson wrote:
> 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
> * {@see 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 <a1...@gmail.com> 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.
>>
>>
>>
>>
>>
>>
>
Re: FTPSERVER - Proposal to add additional SITE command functionality
Posted by Niklas Gustavsson <ni...@protocol7.com>.
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
* {@see 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 <a1...@gmail.com> 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.
>
>
>
>
>
>