2009/1/1 Niklas Gustavsson <[email protected]> > 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. > > > Since a command can (and will) have several reply codes, I would say that > we might probably need a distinction between the sent reply code and the > Result of the operation, don't you think so? I'm probably missing something > here. >
We could add some goodies as a isPositiveCompletion method (and such) as well, but I wonder if in our code FTPReply is the proper place to add these methods. > /niklas >
