In message <[EMAIL PROTECTED]>, steve cohen writes: >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
Agreed. I'm lagging behind the discussions because of the digest, so I said some stupid things :) >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. I also considered that VMSFileEntryParser could manage the removal of duplicates itself, except I saw the need to demarcate the start (and possibly stop) of a listing as a showstopper. It seemed like a special case just for VMSFileEntryParser, in the same way the createIterator idea I suggested seems. I think what we have to discover is the most appropriate general case that encompasses the situation we face with VMSFileEntryParser. If we build special support into FTPFileIterator for handling duplicates, we don't gain any additional flexibility. That's why I favor a way of implementing Jeffrey's iterator filter/adapter idea with as little impact to existing code as possible. It gives additional flexibilty. However, that doesn't mean we don't also need a way to allow entry parsers to maintain state while the parsing of a file listing is in progress. Whether that should be done by adding a new method (indicating the start of a listing; where the cache could be initialized) or an extra parameters to parseFTPEntry (e.g., an integer indicating the number of the entry; 0 indicates the first entry) I don't know. A startListing() or similar method is probably the more flexible approach if we decide that's necessary. I'm of the mind we've run into an architectural weakness and have to rethink how FTPFileList, FTPFileIterator, FTPFileEntryParser, and FTPClient should interact. Right now, we don't have a clear path for extending/customizing FTPFileList and FTPFileIterator behavior as it relates to FTPFileEntryParser instances. Granted, we have only this one case with VMSFileEntryParser to consider, but there may be others lurking around the corner we need to anticipate. I think FTPFileEntryParser is the key to customization. All of our problems would be solved if instead of a static FTPFileList.create method, there were a per-instance FTPFileList createFileList method in FTPFileEntryParser. Although, in that case it would help for FTPFileList to be an interface. Since FTPFileList has a private constructor and API users can only create instances with create(), maybe we can make FTPFileList an abstract class without breaking anything and move the current implementation into a subclass. FTPClient would use the parser createFileList method and VMSFileEntryParser would return an FTPFileList subclass that did the right thing, either by producing a filtering iterator derived from FTPFileIterator or by redefining the way the stream is read. I'm not saying this is the best way to go, but it does offer more flexibility than either of our previous suggestions without breaking anything. At any rate, it's another idea to throw into the pot. Let's brainstorm some more and make a list of pros and cons. daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
