On Wed, Dec 31, 2008 at 2:51 AM, Sai Pullabhotla <[email protected]> wrote: > 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.
Sounds good, this should go into the interface as well. > 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. While I agree that this is cleaner, I don't think we should do this since it severely breaks our API. We'll do this in a future 2.0 release I think. > 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. Right. Again, make these interfaces as well. > 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 - I think we should add the information on the FtpReply sub-interfaces. /niklas
