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>
From: Steve Cohen <scohen@javactivity.org>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: [net] NT FTP Server & DIRSTYLE (was Re: [net] [vote] Release
 Commons-Net 1.2)
Date: Thu, 1 Apr 2004 07:20:30 -0600
User-Agent: KMail/1.5
References: <200403281453.24107.scohen@javactivity.org>
 <200404010622.17900.scohen@javactivity.org> <406C146A.2050209@ops.co.at>
In-Reply-To: <406C146A.2050209@ops.co.at>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200404010720.30409.scohen@javactivity.org>

I think having a Unix parser within the NT parser is not a good design.  I 
think the logical right place to do it is in the factory.  Before I had heard 
about DIRSTYLE I was envisioning a process of getting a test listing when 
SYST returned "Windows" and trying both parsers.  Or some other test.  To be 
done in the factory.  

The DIRSTYLE thing offends because it seems "invasive" but how invasive is it, 
really?  If it only affects the single connection session (which is what I 
would assume), it's not so bad.


On Thursday 01 April 2004 7:08 am, Mario Ivankovits wrote:
> Steve Cohen wrote:
> >So let's here some more comments:  how nasty is this DIRSTYLE toggling
> > thing that some of us are just hearing about for the first time now?
>
> I think we could live with this, but beside this, the question is too,
> how bad it is to implement.
>
> Currently we do have not instance of the FTPClient within the
> EntryParsers, so we have to change createFileEntryParser to
> a) pass a "subtype" (which depends on the host)
> b) to pass the FtpClient instance to do the syst/dirstyle command.
>
> or
>
> c) We do the following withing NTFTPEntryParser
>
>     private final FTPFileEntryParser fallback = new UnixFTPEntryParser();
>     private boolean unixStyle = false;
>
>     public FTPFile parseFTPEntry(String entry)
>     {
>         if (!unixStyle && matches(entry))
>         {
>             FTPFile f = new FTPFile();
> ...cut....
>         }
>         else
>         {
>             unixStyle = true;
>             return fallback.parseFTPEntry(entry);
>         }
>     }
>
>
> Then we do not have to rely on the dirstyle output, and do not have to
> change the interface to the DefaultFTPEntryParser.
> So the ugliness (if you call the above change so ;-) is within the
> initiator - the NTFTPEntryParser and the corresponding host ftp
> implementation :-)
>
>
> If you agree, i could send a patch.
>
> -- Mario
>
>
> ---------------------------------------------------------------------
> 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