From commons-dev-return-49477-apmail-jakarta-commons-dev-archive=jakarta.apache.org@jakarta.apache.org Tue Apr 06 01:20:17 2004 Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 86278 invoked from network); 6 Apr 2004 01:20:16 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 6 Apr 2004 01:20:16 -0000 Received: (qmail 56406 invoked by uid 500); 6 Apr 2004 01:19:55 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 56378 invoked by uid 500); 6 Apr 2004 01:19:55 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 56365 invoked from network); 6 Apr 2004 01:19:55 -0000 Received: from unknown (HELO javactivity.org) (65.118.246.250) by daedalus.apache.org with SMTP; 6 Apr 2004 01:19:55 -0000 Received: from 192.168.123.60 [24.14.39.135] by javactivity.org with ESMTP (SMTPD32-7.07) id A5C2FAB006A; Mon, 05 Apr 2004 20:20:02 -0500 From: Steve Cohen To: "Jakarta Commons Developers List" Subject: Re: [net] NT FTP Server & DIRSTYLE Date: Mon, 5 Apr 2004 20:19:58 -0500 User-Agent: KMail/1.5 References: <200403281453.24107.scohen@javactivity.org> <85wu4us55n.fsf@firefoot.brekke.org> <4071A9C0.2050806@ops.co.at> In-Reply-To: <4071A9C0.2050806@ops.co.at> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200404052019.58852.scohen@javactivity.org> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N When I first read Mario's proposal I was totally against it. It seemed to me that it must be much more complicated than DIRSTYLE. I wrote a whole letter slamming the idea. Then I took a good look at Mario's patch. Now that I have looked it over, I am much more favorable to the idea and compliment Mario strongly on his design. However, there is still one problem that I see: I don't like the way the Composite parser can vary on every entry. Any time it fails to parse an entry, it reopens the question of what type of parser it is. I think the business about iterating through the possible parsers should only happen the first time through. In other words: public FTPFile parseFTPEntry(String listEntry) { if (cachedFtpFileEntryParser != null) { FTPFile matched = cachedFtpFileEntryParser.parseFTPEntry(listEntry); if (matched != null) { return matched; } } // my changes begin here } else { // my changes end here for (int iterParser=0; iterParser < ftpFileEntryParsers.length; iterParser++) { FTPFileEntryParser ftpFileEntryParser = ftpFileEntryParsers[iterParser]; FTPFile matched = ftpFileEntryParser.parseFTPEntry(listEntry); if (matched != null) { cachedFtpFileEntryParser = ftpFileEntryParser; return matched; } } return null; } Assuming that all tests pass, I would not have any problem committing this with my change. On Monday 05 April 2004 1:47 pm, Mario Ivankovits wrote: > Jeffrey D. Brekke wrote: > >Go for it, I probably won't get around to looking at it until tonight > > (CST). > > http://issues.apache.org/bugzilla/show_bug.cgi?id=28215 > > Documented within the Bug-Description and in CompositeFileEntryParser.java > > -- Mario --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org