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>
Content-Type: text/plain;
  charset="iso-8859-1"
From: steve cohen <scohen@javactivity.org>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: [net] 1.2 release (Re: [net] checked in parser factory
 implementation)
Date: Mon, 5 Jan 2004 14:27:22 -0600
User-Agent: KMail/1.4.3
References: <200401051729.i05HTEK2003664@gandalf.savarese.org>
In-Reply-To: <200401051729.i05HTEK2003664@gandalf.savarese.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <200401051427.22405.scohen@javactivity.org>

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