In message <[EMAIL PROTECTED]>, Jeffrey D. Brekke writes: >[Alternatives to VMS Parser/Version issue] > >Another alternative is to create another parser, creating two VMS >parsers, potentially sub-classing one VMS parser to avoid code >duplication. A specialized VMS parser that will filter off multiple >versions. This solves the contract problems with the parsers and
I was about to say "Eureka!, that's the right solution." as far as the specific VMS parser case goes, but there's still the problem of how to make it filter off multiple versions when called using readNextEntry and parseFTPEntry. Unless I'm missing something, we still have to support some hook for the postfiltering. Nonetheless, splitting the VMS parsing functionality into two separate classes (one derived from the other) is cleaner than using the versioning property. >[FTPClient API coherence] > >On the point of the FTPClient api, I was under the impression also >that we were leaning toward a FTPFileList as the norm, and away from >the arrays. Maybe now that we're 1.2 bound, we can just return List >and have FTPFileList implement the List interface ( and Iterator >interface, opening up the possibility of using commons/collections >filter iterator or other collection utilities )? I see Steven and you have made further comments in the thread about this. I'm in favor of whatever provides sufficient flexibility so that API users can customize behavior without requiring us to shoehorn application-specific functionality into the library. I'm not sure about having FTPFileList implement List, or perhaps Collection, but I haven't sorted out my thoughts. There could be considerable advantages. Also, one of the possibilities I threw out was having void listFiles(FTPFileList, ...), where the results are returned in the FTPFileList, which would require at least clear() and possibly add() methods depending on the implementation. >I guess we're spiraling out of control here with ideas ( not >necessarily a bad thing ). Just not sure how to rein us in ;) Although I don't want to put off decisions, we can always take a baby step to resolve the immediate VMS entry parser issue and take some more time to figure out the rest. That is, unless they are inextricably tied ... We've got several options for allowing ant to grab a VMS entry parser with version filtering. I think we've agreed that splitting out the functionality into a subclass is the way to go. But we still need a way to implement the version filtering transparently without depending on parseFileList. daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
