On Tuesday 06 January 2004 12:40 pm, Daniel F. Savarese wrote: > 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 >
After looking at the code, I have a different idea. Reimplementing createFileList() in terms of parseFileList() would negate the whole reason for inventing createFileList() in the first place - your suggestion wishing for a way to postpone the creation of expensive FileList objects until needed. I think the solution should rest within the FTPFileEntryParser concept as implemented by the VMSFileEntryParser. That parser, when working with a versioning system, should maintain its cache of existing entries and not return duplicates. This is similar to what VMSFileEntryParser.parseFileList() does now, except that the cache is a class member and not a local variable. The best place to implement this is in VMSFileEntryParser.parseFTPEntry(). A duplicate entry could return null or else a special value (public static final FTPFile DUPLICATE_ENTRY = new FTPFile();). FTPFileIterator would skip all such instances. The only other thing needed would be a new method in FTPFileEntryParser to reinitialize this cache. The default implementation of this in FTPFileEntryParserImpl would be a no-op but the VMS case there would actually be a cache to empty. This solution preserves all the previous gains without preserving a lot of confusing APIs. It lets us safely deprecate FTPFileListParser. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
