Thanks Daniel! Also, the document Jeff points to (for unit testing protocol stuff) has information that I can use to come up with the unit tests we want for this feature. Will get back to you when I have something concrete to contribute in this direction.
When is the first Jakarta release planned? I hope I am not repeating an oft-asked question! - Tapan. > -----Original Message----- > From: Daniel F. Savarese [mailto:[EMAIL PROTECTED]] > Sent: Friday, September 20, 2002 8:32 PM > To: [EMAIL PROTECTED] > Subject: Re: [patch] NetComponents - FTPClient's restart functionality > > > > >This is a patch to fix the restart functionality in > FTPClient. Following is > >the summary of changes: > > Thanks! I for some reason thought we had applied this when you first > brought it up, but I guess not. I applied it with one minor change. > I allowed the offset to be reset to zero. You might need to do this > when writing an interactive client and the user changes his > mind before > initiating the transfer. > > >A couple of lines in the diff may wrap onto the next line. > If this is a > >problem in applying this patch, how should I upload the patch file to > >someplace from where it can be picked up by you? > > I wound up fixing the linewraps by hand so the patch would take. In > the future, if you include the patch as a MIME attachment rather than > inserting it into your email, it should avoid the line wrapping. But > maybe we'll have voted you in as a committer by then :) > > >Also, can you suggest how can this be unit tested so that I > can write a test > >and send it? > > Testing any of the protocols is tough. One way is to provide a fake > server that reproduces the proper state transitions for each RFC. > This is easy to do by using setSocketFactory() to set a factory on > each client that produces a socket that creates input and output > streams to this state transition engine. However, once you go to > all of that trouble, you might as well write a bunch of full blown > servers. Therefore, it is best to test against some set of servers > that the developer trusts to be reasonably faithful implementations > of the RFC. These could be set in a property file and default to > test servers on the developers machine. So a restart unit test would > involve ftp'ing a known file, reading some random number of bytes > from it, closing the data connection, and then opening a new data > connection, restarting from the end of the local file. After the > transfer is complete, do a binary byte-for-byte comparison of each > file. But we ought to create some skeleton code or a base testing > class(es) that can be used as starting points for writing these > protocol tests. It may not be a bad idea to look at what HttpClient > does. > > Jeff, I was in the habit of maintaining a CHANGES file that recorded > all of the major changes between each version of the software. > Autogenerated changelogs tend to get cluttered with a lot of > extraneous > stuff. What's the equivalent place to store this > information? I don't > want to reconstitute the changes from memory when people start asking > what changed between v1.3.8 and the first Jakarta release. > > thanks, > daniel > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
