Jean-Christophe Collet wrote:
Hello,
I have posted an entry in my blog about the current status of the FTP
client API.
It contains a quick description of the project as well as a link to
the current draft of the API. So if you're interested in that topic go
take a look at http://blogs.sun.com/jcc/
As mentioned in the post, feedback is very strongly encouraged.
I'm interested in reviewing this. From an initial glance this is ftp and
ftps - are you also thinking about sftp? Some initial comments from a
first pass:
It would be better to use a static factory method rather than public
constructors. For one thing, there are a slew of ftp clients about and
you'll likely get requests for a provider interface so that alternative
implementations can be used.
The client has state (not connected, connected, logged, etc.) and you
might want to introduce a few specific exceptions for this. For
example, what does connect throw if you are already connected, what do
the other methods throw when you aren't connected, etc.
In current draft there are quite a few methods that return a boolean and
throw IOException. It's not clear to me what what failure means - do
these methods return false or do they throw an I/O exception? How is
this used with the getLastReplyCode method or should the exception have
a method to return the reply code?
The listFiles returns a List<FtpFile> and isn't going to scale with
large directories (you'll have to fetch the entire directory from the
server for this method to return). It would be better to return
something that implements Iterable<FtpFile> and Closeable.
I'm curious about FtpFile. My memory of the ftp protocol is hazy but I
thought that commands such as LIST or NLIST didn't specify the format of
the file attributes. There was a IEFT WG working on defining these but I
don't see this in the references. Do you have a pointer to that?
I see that the getModificationTime returns a Date. Care to revise your
statement sir :-)
You've got a number of setter methods that return void. It might be
nicer for them to return this so as to facilitate invocation chaining.
Should the members of the TransferMode enum be in uppercase?
Do you really need the ability to set/get the connect timeout and allow
it be overridden by the connect method?
That's it for a first pass.
-Alan.
