You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Daniel F. Savarese" <df...@savarese.org> on 2004/09/27 19:02:42 UTC

Re: [net]Enabling FTPClient to set bufferSize

In message <MJ...@eircom.net>, "Rory Winston" w
rites:
>I have patched FTPClient to enable explicitly setting the buffer size. Can
>anyone else on [net] give this a quick once-over? I don't think I have
>missed anything, but just in case...

It looks fine to me.  All references to Util.DEFAULT_COPY_BUFFER_SIZE
were replaced with getBufferSize() and __bufferSize was initialized
to a default value in the constructor.

BTW, thanks for all of the work you've done in such a short time.  You've
taken care of more than a couple lingering TODOs.

daniel



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


RE: [net]TODOs for 1.3.0?

Posted by Rory Winston <rw...@eircom.net>.
Great. I think it *may* be possible in the not-so-distant future to push out
a 1.3.0 release. I've looked at the TODO list, and here it is as it stands,
plus a couple of issues that have come up in the meantime:


Pre-1.2 Tasks

    * VMS parser issue [DONE]
    * Review of the NTP/SNTP code [DONE]
    * Scan the bug list [IN PROGRESS]

Wishlist

    * Add programmer and acceptance tests.
    * Convert code to specified coding standards. Checkstyle report
provided.
    * Clean out any classes that don't belong in this project. Probably
classes from org.apache.commons.net.util and org.apache.commons.net.io could
be moved to their corresponding commons projects.
    * Make buffer size settable for FTP data transfers using retrieveFile().
retrieveFile() uses Util.copyStream and a 1024 byte buffer which is too
small for some applications (Solaris SMP). [DONE]
    * Divorce FTPClient from TelnetClient, getting rid of the TelnetClient
threads which cause problems on some platforms (e.g., MacOS).
    * Parse the client/server interactions without creating so many strings.
Many operations are slow because of this.
    * Add ESMTP and extended NNTP commands (e.g., NNTP authentication).
[Some NNTP commands added - XOVER, XHDR, LIST ACTIVE, AUTHINFO]
    * Make NNTPClient.listNewsgropus() and NNTPClient.listNewNews() more
efficient. Don't preparse into lots of little objects.
    * TLS for FTP
    * Change build so that API documentation doesn't include private and
package private members. [DONE]
    * Change build so that javadoc generation doesn't have unit testing as a
prerequisite. [DONE - still depends on get-deps, though]
    * Change jar generation so that it doesn't include example classes.
[DONE - will commit]


A couple of other issues that have arisen:

1. A mechanism for extensible date handling in FTPClient - we're looking at
this now
2. I've seen some mails on the user list, and one or two in BugZilla,
related to encoding issues. I notice that somebody has submitted patches to
get FTPClient working with a Japanese locale
(http://issues.apache.org/bugzilla/show_bug.cgi?id=30719). Would there be
any merit in trying to apply the selectable encoding approach?
3. Re:  Divorcing FTPClient from TelnetClient - I see that someone has
submitted a patch (http://issues.apache.org/bugzilla/show_bug.cgi?id=30970)
that extends SocketClient instead of TelnetClient - would it be feasible (or
advisable) to apply this?
4. Re: the NNTP performance issues, I've made false starts on this many
times, I haven't had a chance to spend sufficient time to get any results.

I dont know if the various FTPClient improvements plus the NTP/SNTP support
would be worth an extra release. I know that a new date handling mechanism
plus a change in the way that we handle  encoding schemes *would* be,
though. So I'll put this question to the list - what do the other developers
think would be a must for 1.3.0?

Cheers,
Rory


-----Original Message-----
From: Daniel F. Savarese [mailto:dfs@savarese.org]
Sent: 27 September 2004 18:03
To: Jakarta Commons Developers List
Subject: Re: [net]Enabling FTPClient to set bufferSize



In message <MJ...@eircom.net>, "Rory
Winston" w
rites:
>I have patched FTPClient to enable explicitly setting the buffer size. Can
>anyone else on [net] give this a quick once-over? I don't think I have
>missed anything, but just in case...

It looks fine to me.  All references to Util.DEFAULT_COPY_BUFFER_SIZE
were replaced with getBufferSize() and __bufferSize was initialized
to a default value in the constructor.

BTW, thanks for all of the work you've done in such a short time.  You've
taken care of more than a couple lingering TODOs.

daniel



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org