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 Mon, 05 Jan 2004 22:34:55 GMT
Except for the issue outlined below (re FTPFileListParser deprecation) my 
latest commit have implemented everything that Daniel discussed earlier 
today:  

Cleanup of File parsing interface:
  Deprecate class DefaultFTPFileListParser
  Remove __defaultFileListParser from FTPClient
  Deprecate FTPClient.listFiles() methods that take a FTPFileListParser param
  For those FTPClient.listFiles() methods that do not take a FTPFileListParser
  param, reimplement as per previous FTPClient.getFileList() methods
  Remove FTPClient.getFileList methods
  Change ParserInitializationException to inherit from RuntimeException
  Add FTPFileEntryParserFactory member to FTPClient and initialize this
  member to a new DefaultFTPFileEntryParserFactory.  Add a set() method
  for this member.  Remove logic that attempts to initialize this member
  based on a system property.

Once we have agreement on what to do about FTPFileListParser, I can make those 
changes as well

Steve
  


On Monday 05 January 2004 02:27 pm, steve cohen wrote:
> There's still one problem with deprecating FTPFileListParser.
> The one method of this interface (parseFileList()) is used in the
> VMSFTPEntryParser.  There is an implementation here that is distinct from
> the default one in FTPFileListParserImpl.
>
> This is for a very good reason.  The idea of a File Entry parser (as
> opposed to a File List parser) was to parse each entry separately.  This
> was a good idea and allowed for cleaner logic to be used.  It made the
> business of not creating FTPFile objects until needed possible.
>
> The only problem here was in the VMS case where versioning is turned on. 
> In that case the question of whether or not to "keep" an entry depends on
> the existence of other entries with the same name and different version
> numbers. In that case you do want a whole-list parsing mechanism.
>
> If we still want to deprecate FTPFileListParser, I would recommend, then,
> that we move parseFileList() into the FTPFileEntryParser interface. 
> However, I wanted to throw this question out there for general comment
> before I do that.
>
> On Monday 05 January 2004 11:29 am, Daniel F. Savarese wrote:
> > I forgot to add that I think we need a beta release for 1.2 to give us
> > a chance to back out or fix anything that we discover is suboptimal
> > before we set the stuff in stone in the API.  Mostly I'm thinking of
> > method signatures.  Anyway, to recap the proposed deprecation list:
> >
> >   interfaces:
> >        FTPFileListParser
> >   classes:
> >        DefaultFTPFileListParser
> >   methods:
> >        FTPClient.listFiles(FTPFileListParser, String)
> >        FTPClient.listFiles(FTPFileListParser)
> >
> > Did I miss anything?
> >
> > daniel
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


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