Thanks for the reply,

My FTPClient knowledge is obviously a bit lacking as it hadn't really
clicked that FTPClient inherits from SocketClient.

Jake


On Sat, Nov 9, 2013 at 12:05 AM, Daniel Savarese <d...@savarese.org> wrote:

>
> In message <
> cantdsqb3ne5bpshj1u07td0xtoj3sdhw_b3spwe8ef2w9hw...@mail.gmail.com>
> >While using FTPClient on an Android application I was developing, I found
> >myself wishing I could attach a CountingInputStream to LIST requests. This
> >was because I was requesting very large file lists on a slow connection.
>
> This is just a suggestion.  The simplest way to achieve your goal with
> no code modifications is to:
>
> 1. Subclass java.net.Socket and override getInputStream() so that it
>    wraps the result of super.getInputStream() with CountingInputStream.
> 2. Implement a javax.net.SocketFactory that returns such sockets and use
>    it with FTPClient via SocketClient.setSocketFactory.
>
> That will only work for passive mode (see _openDataConnection_()).  If not
> using passive mode, then you need to a little more work, but can still
> accomplish your goal via wrappers and a custom ServerSocketFactory.
>
> >I thought I could contribute to the net.ftp project by adding a method to
> >the api that somehow exposed the stream, so that users can do what they
> >want with it.
>
> I would suggest that any such feature be implemented via the generic
> route I described (i.e., add the support classes to make it easy to
> do) instead of a feature-specific manner.  Given the current hooks,
> it should not require any modifications to FTPClient.  That is just
> my opinion and nothing more.  A class that delegates all operations to
> Socket that can be easily subclassed to override Socket functions could
> be useful (along with a similar one for ServerSocket), making it easy
> to implement arbitrary customizations in conjunction with socket factories.
>
> daniel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Reply via email to