A proposal for a FTP client API

[Alan Bateman]

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.