commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel F. Savarese" <>
Subject Re: [net] 1.2 release (Re: [net] checked in parser factory implementation)
Date Tue, 06 Jan 2004 22:21:43 GMT

In message <>, Jeffrey D. Brekke writes:
>Couldn't we handle this with a FilterIterator or some other adapter on
>the iterator from an FTPFileList?  I never thought of this when the
>version patch was submitted, but it seems like a possible solution.
>Better than supporting multiple ways of parsing the list.

I misunderstood what was going on with VMSFTPEntryParser (no point
in explaining how I was misunderstanding it).  Forget about anything
I said about parseFileList and let's back out my addition of the method
to FTPFileEntryParser.  Am I correct to say that VMSFTPEntryParser
filters out duplicate entries when versioning is turned off?
If that's the case, attaching an adapter/filter to the iterator is
a good way to go.  How do we do this transparently?  The way the
classes fit together right now, I don't see how to slip in an
adapter transparently.  One way to do it would be to add an
FTPFileIterator createIterator(FTPFileList) method to
FTPFileEntryParser and have FTPFileList call that to get the
iterator in FTPFileList.iterator().  FTPFileListParserImpl
would return an FTPFileIterator and so would all of its
subclasses, except VMSFTPEntryParser which would override the
method and return its own iterator that filters out duplicates
when versioning is off.  I'm not crazy about my suggestion
for implementing your suggestion because it's a workaround and we
shouldn't add new methods to interfaces to handle special cases.  If
there is a design weakness in the way FTPFileList, FTPFileIterator,
FTPFileEntryParser, and FTPClient interact, let's nail it down, fix it,
and migrate.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message