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