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>
Message-Id: <200401010442.i014gIg9027419@gandalf.savarese.org>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug? 
In-reply-to: Your message of "Wed, 31 Dec 2003 11:07:40 CST."
             <200312311107.41013.scohen@javactivity.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 31 Dec 2003 23:42:18 -0500
From: "Daniel F. Savarese" <dfs@savarese.org>


In message <200312311107.41013.scohen@javactivity.org>, steve cohen writes:
>I am not completely CVS-literate and setting up the branches is beyond my 
>current level of experience but probably would be good experience for me.

In my response to Jeffrey's email, I asked about whether we wanted to
replace the existing NET_1_1_0 tag with a new NET_1_1_0 branch tag or
leave the existing tag alone and attach a special branch tag with a different
name to the NET_1_1_0 files.  After we resolve that, if you want to do
it, go ahead.  I don't know if you can use the -F and -b options together
with cvs tag, which is why I suggested the roundabout way of renaming
the tag and creating a new one with the old name using -b.  Subversion
makes this easier.

>without requiring it to have far more knowledge of commons-net internals than 
>I think is healthy.  So I am developing an FTPFileEntryParserFactory and some 
>convenience methods in FTPClient to enable Ant to be recoded decently.

I followed the emails.  Sounds great.  I forgot to offer a comment.
I was going to suggest making FTPFileEntryParserFactory either a
class or an interface that has to be instantiated rather than
a singleton.  I think you were intending to make createFileEntryParser
a static method.  I suggest the use of an interface and a default
factory class for the same reason we had to write SocketFactory and
much later, in J2SE 1.4, Sun added its own javax.net.SocketFactory
and javax.net.ServerSocketFactory.  It allows generic code to be
written that accepts pluggable parser factories should a user decide
to implement his own factory.  I'm thinking about the automatic
detection code you alluded to, which could then be configurable/extensible
through the insertion of parser factories.

>I can also make the HashMap-->Hashtable change for the 1.1.1 branch.  The JDK 
>1.1 incompatibility was DISCOVERED through failure of the unit test but the 
>offending code is in the class being tested, not the test itself.  I have 

Sure thing.  Let's decide how to tag that branch.

>And it sounds like you have an itch for doing the nio stuff.

It's been nagging me for a while, but I'm actually writing networking
code these days based on java.nio, so I figure I should kill two
birds with one stone and start rolling it into Commons Net as
a proposal instead of keeping it in my private library.  It's so
much easier to dedicate volunteer committer hours when you're
working on/using the stuff anyway.

daniel


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org