In message <[EMAIL PROTECTED]>, steve cohen writes: >There's still one problem with deprecating FTPFileListParser. >The one method of this interface (parseFileList()) is used in the >VMSFTPEntryParser. There is an implementation here that is distinct from the >default one in FTPFileListParserImpl. ... >If we still want to deprecate FTPFileListParser, I would recommend, then, that > >we move parseFileList() into the FTPFileEntryParser interface. However, I >wanted to throw this question out there for general comment before I do that.
In one of my emails I started writing "I'm not entirely convinced we need to deprecate FTPFileListParser ..." but I couldn't really support that so I deleted that thought. You nailed the case where it makes a difference. The question remains though, how do we support this when the only way parseFileList is called is in listFiles(FTPFileListParser, ...), which we're deprecating and going to remove? I don't think we want the API user to have to be intimate with the different parsers and figure out when to call listFiles(FTPFileListParser, ...) and when not to. Moving parseFileList into FTPFileEntryParser won't solve the problem unless we make parseFileList the single entry point to creating file lists from FTPClient (since all of the FTPFileEntryParser implementations we have so far implement parseFileList). 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. daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
