Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-Id: <200401090922.i099MKjA023422@gandalf.savarese.org>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: [net] 1.2 release (Re: [net] checked in parser factory
 implementation) 
In-reply-to: Your message of "Wed, 07 Jan 2004 13:38:27 CST."
             <200401071338.27953.scohen@javactivity.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 09 Jan 2004 04:22:20 -0500
From: "Daniel F. Savarese" <dfs@savarese.org>


In message <200401071338.27953.scohen@javactivity.org>, steve cohen writes:
>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.

I went ahead and made the changes I had put out for discussion (see
comments in CVS commit log).  It seemed easier to make them and let you
improve on them or revert them.  There should be no impact on existing code.
However, I had to introduce createFTPFileList into the FTPFileEntryParser
interface.  I don't like the name of this method.  It's basically an
FTPFileList version of parserFileList.  If we keep this change, we should 
ome up with a more appropriate name.

There are some things I didn't understand in FTPFileListIterator (now
an abstract class with DefaultFTPFileListIterator containing the
implementation code).  Is getNext(0) supposed to return all remaining
elements and getPrevious(0) all elements between 0 and the current
position?  Also, FTPFileList.getFiles() (now DefaultFTPFileList.getFiles()
with FTPFileList being an abstract class) was returning iterator().getNext(0).
I changed this to iterator().getFiles(), which was less confusing to me.
But it seems that getFiles() actually does something different than
getNext(0), reinitializing the current position.  Is there something that
needs to be fixed there?  I didn't want to change anything there.
Please doublecheck VMSFTPEntryParser.DuplicateFilteringIterator to
ensure it implements the getNext() and getPrevious() methods as
intended.  I included little comments saying how I interpreted the 0
argument.

I didn't fix up all affected javadocs (too late, too tired).  I also
didn't split out VMSFTPEntryParser into two classes, but that should
be easy for anyone else to do.  Basically, all I did was shuffle code
around to make user customization easier.  The only new code I wrote
were a couple of methods in DuplicateFilteringIterator, but it really
just grafts part of the old parseFileList which is now split between
DuplicateFilteringIterator and createFTPFileList().

daniel


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org