commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rory Winston (JIRA)" <>
Subject [jira] Closed: (NET-166) [FTP] FTPClient should be an Interface
Date Tue, 19 Feb 2008 22:32:43 GMT


Rory Winston closed NET-166.

    Resolution: Later

> [FTP] FTPClient should be an Interface
> --------------------------------------
>                 Key: NET-166
>                 URL:
>             Project: Commons Net
>          Issue Type: Improvement
>    Affects Versions: 2.0
>            Reporter: Stefan Tauner
> imho the FTPClient inheritance hierarchy should be changed as follows:
> FTPClient should be renamed to something else (e.g. FTPClientImpl).
> a new Interface named FTPClient should be introduced which should be implemented by both,
the old FTPClient and FTPSClient.
> shared code should be extracted and inherited.
> why?
> because atm its not possible (pls correct me if im wrong!) to extend the ftp classes
in such a way, that the resulting classes could have a common superclass other than FTPClient.
> e.g. i want to implement caching of dirlistings
> the easiest way would be to define an interface CachingClient which extends the new FTPClient
interface with a method like
> public FTPFile[] list(String dir, long timeDeltaMS) throws IOException;
> one could then create two new classes CachingFTPClient and CachingFTPSClient, which would
implement the CachingClient interface and extend either FTPClientImpl or FTPSClient.
> that way you could have two caching client classes with a common parent class/interface
other than the current FTPClient, which is highly restrictive when extending the current FTPClient
classes: i cant use any other method than those specified in FTPClient, if i want to share
the source from both client implementations.
> another option to implement a feature like caching would be a proxy, but one would have
to forward all current FTPClient methods inside the proxy object, which isnt very neat.
> third option would be to use FTP directly, but thats a lot of unnecessary work too.
> i hope someone can understand what i wrote :)
> cons: this would break client code, that tries to instantiate FTPClient.
> thats a reason to change it before the release of commons net 2.0. btw
> id be glad to help with this, if you contact/instruct me :)
> edit: what i havent thought about, is, that current FTPClient extends class FTP, which
extends abstract class SocketClient
> crap. :(
> ill leave this issue open, because id like to hear some comments anyway

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message