I wrote: >Looking at the code, I would have to agree that parseFileList should >be preserved and move into FTPFileEntryParser. That allows us to >rewrite createFileList to call parseFileList instead of >FTPFileList.create, which allows the VMSFTPEntryParser to continue >doing its thing.
Scratch that. I didn't realize how FTPFileList worked and where it was used. There may be a fundamental incompatibility here. In any case, I tested deprecating FTPFileListParser and adding the parseFileList method to FTPFileEntryParser. It doesn't cause any compilation or runtime problems. So that's a viable migration path. The problem that remains is in how to invoke parseFileList() when required (i.e., for VMSFTPEntryParser). The whole point of FTPFileList and FTPFileEntryParser was to perform incremental parsing, but parseFileList requires parsing of the entire input in advance. One way out of this is to add a boolean requiresEntireStream or similar method to FTPFileEntryParser, which FTPFileList can use to decide whether to call parseFileList, but that invites other kluges because FTPEntryParser implementations implement parseFileList by creating an FTPFileList in turn. I don't have a suggestion about this right now. Another question is whether we should encourage the use of FTPFileList over FTPFile[] for iterating over file listings. I thought that's where we were headed with Steve's code. Wouldn't that suggest we should deprecate FTPClient.createFileList and replace it with FTPFileList listFiles? We can get away with that because the createFileList methods have diferent signatures from the existing listFiles methods. But wouldn't we want to replace the existing FTPFile[] listFiles methods with ones that return FTPFileList? Alternatively, FTPFileList could be passed as a reference parameter to a void method (e.g., void listFiles(String pathname, FTPFileList list)), which would require a couple of modifications in FTPFileList, but would have the benefit of allowing the reuse of FTPFileList objects without creating garbage. Or is there no real gain to be had down that road? daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
