On Wednesday 07 January 2004 11:44 am, Daniel F. Savarese wrote: > 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.
I think we're all in agreement here. The subclass is cleanest the way to go. (See, Jeffrey, that wasn't so hard). I also agree that there is a need for postfiltering (to solve the "most recent version only" problem), although, actually, I think prefiltering out the dupes may be the way to go. Either way, some kind of hook will be necessary, one that's a no-op in the default case. If time gets to be a factor we can leave this as a known issue for later. No one's actually complained about it other than me, from reading the code. > > >[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 > > Frankly I think we could have this coded by the weekend if not sooner. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
