I started working on this and need to know what you guys think of the following:
Instead of having a start time and end time in the FtpReply interface - what if we have receivedTime in the FtpRequest object and sentTime in the FtpReply. This potentially serves the same purpose - when an Ftplet wants to know the start time, end time or total time taken by a command. Also, as David suggested, I would also like to add a few methods to the FtpReply interface to indicate if the reply was positive, negative etc. Let me know what you think. Regards, Sai Pullabhotla Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com On Thu, Jan 1, 2009 at 12:45 AM, Niklas Gustavsson <[email protected]> wrote: > 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 >
