Niklas,
I'm planning on working on the issue FTPSERVER-253
(http://issues.apache.org/jira/browse/FTPSERVER-253) over this weekend
and want to make sure we are on the same page.
Essentially below is what I'm planning on doing:
Enhance the DefaultFtpReply to hold some additional information such
as startTime (time when the command started executing), endTime (time
when the command finished executing). Ftplets may want to know this
information.
Change the signature of the Command.execute to return the FtpReply
(this may not be needed, but I think it makes more sense to do it this
way rather than storing the "lastReply" in the FtpSession. I
definitely prefer this approach.
Create subclasses of FtpReply where Ftplets may want to know
additional information about the result of a command. For example, the
RNTO command returns a RenameFtpReply would contain the fromFile and
toFile information.
I don't think we will have too many subclasses of the DefaultFtpReply,
but I will see what I can do when I dig into the code.
One thing I'm still debating on is - if we really should use FtpReply
objects to provide this additional information or create yet another
abstract class (call it Result) and call back the Ftplet afterCommand
method with the Result instead of the FtpReply. This Result would
contain the FtpReply plus any other information. I prefer this solely
based on the logical structure/naming of the objects. Both approaches
would work fine, except the backward compatibility issue if we decide
to go with the new Result object. To be more specific, the Result
class would look like -
public abstract class Result {
private FtpReply reply;
private boolean success;
private long startTime;
private long endTime;
}
A sub class of Result, RenameResult would look like -
public abstract class RenameResult extends Result {
private FtpFile from;
private FtpFile to;
}
I will let you call on if we should just keep everything in the
FtpReply vs the new Result class.
Regards,
Sai Pullabhotla
Phone: (402) 408-5753
Fax: (402) 408-6861
www.jMethods.com
On Fri, Dec 26, 2008 at 1:03 PM, Niklas Gustavsson <[email protected]> wrote:
> On Fri, Dec 26, 2008 at 5:26 PM, Sai Pullabhotla
> <[email protected]> wrote:
>> The purpose of the session ID is just for logging purposes. Let us say
>> I open two simultaneous connections to the FtpServer from my PC both
>> using the same user name, and do several file operations. While we
>> have the remote client's information such as IP address, there is
>> really no way to tell what command was executed from what session.
>> Providing a session ID (which could be the one from Mina) will help
>> associate an action with a specific session. The server administrator
>> can see the exact sequence of commands that were executed in a
>> particular session. Hope this makes sense.
>
> I see, that would be a simple improvement, feel free to open a JIRA
> issue and I'll fix it right away.
>
>> I will be glad to take up the command/reply related changes I
>> mentioned. Will submit a patch soon. I will open a JIRA for this.
>
> Great!
>
> /niklas
>
