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 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. Sai Pullabhotla Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com On Fri, Dec 26, 2008 at 10:01 AM, Niklas Gustavsson <[email protected]> wrote: > On Fri, Dec 26, 2008 at 3:01 PM, Sai Pullabhotla > <[email protected]> wrote: >> Make a method available in the FtpSession which returns the session >> ID. Basically, we need to maintain a session for every control >> connection. This helps determine tracking of a particular session even >> if simultaneous connections came from the same client machine/router. > > Could you please explain this further? We already maintain a session > for each connection (well, MINA does it for us). It does not have a > session ID, but I'm not sure I see the need for it? > >> Change the signature of Command.execute() to return some object. This >> object should contain all the information about the result of the >> execution. This object could be FtpResponse or a new object, Result. >> This result should be made available to the Ftplets afterCommand >> method so the Ftplet implementations can know all about the result of >> the command. For example, a RenameResult could contain the from file, >> to file, file size etc. Where as a RetrieveResult could contain the >> file that was downloaded, its size and may be how long it took etc. > > As you're aware, we already pass the FtpReply to Ftplets. I agree that > we should enhance this by providing subclasses of FtpReply that > provide additional details on the result, like the renamed file and so > on. I would like to do this soon after 1.0. If you want to hack away > at this, feel very welcome :-) > > /niklas >
