commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From steve cohen <sco...@javactivity.org>
Subject Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
Date Wed, 07 Jan 2004 19:38:27 GMT
On Wednesday 07 January 2004 11:44 am, Daniel F. Savarese wrote:
> In message <85n0909wnm.fsf@brekke.org>, 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message