commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Cohen <>
Subject Re: [net] Submission of Configurable Timestamp parsing for FTP Listings
Date Tue, 04 Jan 2005 02:46:56 GMT
Hi, Mario, Happy New Year!

I certainly did think about your suggestions.  And I am not the least
surprised that you immediately want to implement a composite.  You do
seem to be in love with the Composite pattern! :-)

But here is where I drew the line.  I think we are talking about
entirely different use cases.

My use case is a user who has to talk to a particular non-"standard" FTP
server.  He already knows or can easily discover its properties.  He
wants to write a program (or Ant Script, once Ant supports the new
FTPClientConfig way of doing things) and that is that.  Runtime
discovery of the properties of the server he is working with are not the
point for such a user and will only slow his application down.  Such a
user doesn't even need the system-type autodetection, let alone a
composite. Configuration via calls to a few String setters fits within
this scenario.  Configuration via passing objects around does not.  ike
Ant should not have to create parser objects in order to use commons-net
for its ftp task.

I presume that your use case is the use case of VFS, although I must
admit that I really don't understand its utility.  I'm not sure what
problems this vastly self-configuring parser solves.  But that is really
beside the point.

In any case, the autodetection mechanism you need could be built outside
of commons-net as well as within it. There is the method
FTPClientConfig.getSupportedLanguageCodes() to help you query the
capabilities of the system.  You could use it to build an array
of SimpleDateFormats and build some sort of scheme to iterate through
the whole bunch, trying each one in order, or whatever you want to do.

That is the approach I would recommend to you.  The point is that your
use case and my use case are different, and I can't implement yours
without making the FTPClient more unwieldy and more confusing for the
user than I want it to be.

But there is also a second possibility.  There is nothing preventing you
from building your system as an alternative WITHIN the commons-net
package structure, if working through the default FTPClientConfig
mechanism is too prosaic for your tastes:

First, note that FTPClient itself now implements the new Configurable
interface.  You could define a composite version of FTPClientConfig as
an extension of FTPClientConfig and define alternative factory class
other to DefaultFTPEntryParserFactory, and specify this in the
FTPClient.configure() method itself.

if (config instanceof SuperDuperFTPClientConfig) {
__parserFactory =

Then initiateListParsing() would invoke your factory instead of the
default one which could do whatever you need it to do.  Actually, you
don't even need and FTPClientConfig in order to do that, you could just
call FTPClient.setParserFactory().

My logic is simple, and works for my use case.  The composite pattern
previously introduced made developing the Configurable setup harder than
it needed to be.  It wasn't until I realized that users in my use case
neither needed nor wanted any autodetection, that I was able to cut the
cord.  Take a look at the changes I had to make to
DefaultFTPFileEntryParserFactory to accomodate your Composite patterns
and the new ones.  That's as far as I  want to go in that direction.  If
you want different functionality, you should develop your own factory.
That's what the FTPFileEntryParserFactory interface is for.

So to reiterate, I see two options.
1) work within the current setup from the outside, passing in
FTPClientConfigs and build your composite detection scheme outside of Net or
2) write your own Parser Factory and possibly FTPClientConfig subclass
and then, with just a small change to the current system, you could hook
your factory in with the logic you need, unencumbered by the
restrictions of the old system.

If I still don't have enough hooks for you, I can consider ways of
building them in.  And some further refactoring - extracting interfaces,
if that buys you anything.  Try either approach and let me know where
the bottlenecks are.  We can certainly make changes.

But I won't be willing to change the default FTPClientConfig to pass
objects more complicated than strings around.  It confuses the issue of
my use case and violates the simple and clear design of the class which
is a simple container of configuration strings.

Mario Ivankovits wrote:
> Hi Steve!
> Lot of work!
> But there is one thing is miss. After a first look at your checkins it 
> seems it is not possible to replace the FTPTimestampParserImpl by a 
> custom implementation.
> It would be nice to have this to build a CompositeFTPTimestampParser 
> which is able to hold multiple FTPTimestampParserImpls configured for a 
> couple of languages one has to deal with. You know ;-) I would like to 
> "guess" the right one.
> I know you are against this strategy ...
> Said that I would like to suggest to change the FTPClientConfig to not 
> to hold the configuration of the TimestampParser but to hold a already 
> configured TimestampParser.
> Lets speak in meta-code:
> TimestampParser europeTimestamps = new SimpleDateTimestampParser();
> europeTimestamps.setRecentDate(lsjgklsjgdkl);
> .
> .
> FTPClientConfig conf = new FTPClientConfig(NT);
> conf.setTimestampParser(europeTimestamps);
> That way any parser could be written without having to "ignore" the 
> default configration strategy.
> Just an idea!
> ---
> Mario
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message