commons-dev mailing list archives

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

I wrote:
>Looking at the code, I would have to agree that parseFileList should
>be preserved and move into FTPFileEntryParser.  That allows us to
>rewrite createFileList to call parseFileList instead of
>FTPFileList.create, which allows the VMSFTPEntryParser to continue
>doing its thing.

Scratch that.  I didn't realize how FTPFileList worked and where
it was used.  There may be a fundamental incompatibility here.
In any case, I tested deprecating FTPFileListParser and adding
the parseFileList method to FTPFileEntryParser.  It doesn't
cause any compilation or runtime problems.  So that's a viable
migration path.  The problem that remains is in how to invoke
parseFileList() when required (i.e., for VMSFTPEntryParser).
The whole point of FTPFileList and FTPFileEntryParser was to
perform incremental parsing, but parseFileList requires
parsing of the entire input in advance.  One way out of this
is to add a boolean requiresEntireStream or similar method
to FTPFileEntryParser, which FTPFileList can use to decide
whether to call parseFileList, but that invites other kluges
because FTPEntryParser implementations implement parseFileList
by creating an FTPFileList in turn.  I don't have a suggestion
about this right now.

Another question is whether we should encourage the use of
FTPFileList over FTPFile[] for iterating over file listings.
I thought that's where we were headed with Steve's code.
Wouldn't that suggest we should deprecate FTPClient.createFileList
and replace it with FTPFileList listFiles?  We can get away
with that because the createFileList methods have diferent
signatures from the existing listFiles methods.  But wouldn't
we want to replace the existing FTPFile[] listFiles methods
with ones that return FTPFileList?  Alternatively, FTPFileList
could be passed as a reference parameter to a void method
(e.g., void listFiles(String pathname, FTPFileList list)),
which would require a couple of modifications in FTPFileList,
but would have the benefit of allowing the reuse of FTPFileList
objects without creating garbage.  Or is there no real gain to
be had down that road?

daniel



---------------------------------------------------------------------
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