Copyright
---------
Please read the copyright statement and license agreement in the
COPYRIGHT and LICENSE files before using the package.  NetComponents
is now distributed under the LGPL and the copyright is owned by Daniel
Savarese.


Background
----------
This is the 1.3.8 version of NetComponents, an Internet protocol
suite Java library originally developed by ORO, Inc.  This version
supports Finger, Whois, TFTP, Telnet, POP3, FTP, NNTP, SMTP, and some
miscellaneous protocols like Time and Echo as well as BSD R command
support.  The purpose of the library is to provide fundamental
protocol access, not higher-level abstractions.  Therefore, some of
the design violates object-oriented design principles.  Our philosophy
is to make the global functionality of a protocal accesible (e.g.,
TFTP send file and receive file) when possible, but also provide
access to the fundamental protocols where applicable so that the
programmer may construct his own custom implementations (e.g, the TFTP
packet classes and the TFTP packet send and receive methods are
exposed).

NetComponents was originally a commercial product, but after ORO
dissolved, it was continued to be made available for those who found
it useful.  However, no updates have been made since version 1.3.8,
released in 1998.  Yet the library continues to be very popular.  Now
that certain contract obligations have expired, it is possible to make
the source code freely available under the LGPL.


Building
--------

You need Ant (http://jakarta.apache.org/ant/) to build the source
code.


What about NetComponents 2.0?
-----------------------------

The original version of NetComponents was written in a very short
amount of time and subsequent maintenance releases have built on top
of that original "good enough, but flawed" design.  If I were to do
it again, I would do it completely differently.  That is a pretty
common theme in software development.  The experience you gain from
exploring a problem space in the first version of a piece of software
teaches you enough to know how to do the same thing better.

A NetComponents 2.0 would be a completely new piece of software.
However, the factors that led to the development of NetComponents 1.x
are no longer present, and I have no inclination to do the grunt work
for NetComponents 2.0.  The implementation of IETF protocols is simple
and uninteresting.  Even though designing useful and well-designed
software interfaces combined with an efficient implementation is
always a challenge, I am not working on any projects that require the
functionality, flexibility, or efficiency that a NetComponents 2.0
would deliver.  It is the nature of opens source software development
to be driven by the needs of its users.  I don't have any need for a
new version of NetComponents, but many of its users do.

Continued development of NetComponents will have to be driven by the
NetComponents user community.  Jon Stevens had suggested that
NetComponents be donated to the Apache Jakarta Project
(http//jakarta.apache.org/) at the same time the software that is now
Jakarta-ORO (http://jakarta.apache.org/oro/) was donated.  I wanted to
wait and see how Jakarta-ORO worked out before going forward with a
proposal to donate NetComponents.  My experience with Jakarta-ORO has
been disappointing.  Many developers use the software and report bugs
(many of which aren't bugs), but few, if any, are willing to help
advance the development of the software, leaving me as both a
bottleneck and a slave to Jakarta-ORO development.  I will see through
my commitment to fix bugs and develop the next major version of
Jakarta-ORO with Perl 5.6 compatability, but I do not wish to have the
same thing happen with NetComponents.  The user community must be
willing to continue developing the software and share their patches,
or there will be no Jakarta release.

Jon Stevens successfully led the proposal effort for Jakarta-ORO and
probably would have done so for NetComponents as well.  But now that
the window of opportunity has passed, I would have mount a proposal
effort, or, ideally some other Jakarta member or avid NetComponents
user.  There are a series of conditions that a proposal has to meet
(http://jakarta.apache.org/site/newproject.html) before it can be
voted on; and I want to ensure that NetComponents has a strong user
community before a donation attempt is made.

So the onus is on you, the NetComponents user, to see that
NetComponents continues to be developed.  First, we need a mailing
list.  I do not wish to become a slave to NetComponents, so I will not
do anything other than apply patches and distribute the software from
my web site.  Someone needs to set up a developer mailing list where
people can post patches.  I'll maintain a web page with links to all
resources, but that's it.  After we've established that there is
active interest in developing the software, as a member of the Jakarta
PMC, I will put forth a proposal to bring NetComponents under the
Jakarta fold.  Ideally, some other Jakarta member will volunteer to do
this so we can start off with several developers who are already
Jakarta committers.  I will not in any way support or condone the
further development of NetComponents through SourceForge.

Future Work
-----------

NetComponents is "good enough" for a lot of tasks, but it has some
major flaws.  If you want to contribute, here are just a few things
that could use some work:

1. DefaultFTPFileLister doesn't work with every FTP server.  Some
   Microsoft and VMS FTP servers foil it.  It is also wasteful of
   memory in that it parses the listing into a complete set of FTPFile
   instances when it could store the listing and just parse the
   listing on demand through an iterator.  An FTPFileListParser
   implementation should be created that is backed by the original
   listing and iterates through it using a regular expression.
   Regular exxpressions could be installed based on FTP server system
   id's, so when a user runs across an unsupported server, he can
   register a regular expression rather than create a completely new
   hand parsesd FTPFileLister implementation.

2. 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).

3. Divorce FTPClient from TelnetClient, getting rid of the
   TelnetClient threads which cause problems on some platforms (e.g.,
   MacOS).

4. Parse the client/server interactions without creating so many
   strings.  Many operations are slow because of this.

5. Add ESMTP and extended NNTP commands (e.g., NNTP authentication).

6. Make NNTPClient.listNewsgropus() and NNTPClient.listNewNews() more
   efficient.  Don't preparse into lots of little objects.

7. TLS for FTP

Contact Information
-------------------

All correspondence regarding NetComponents should be sent to
netcomponents at oroinc.com.  I will not answer support questions,
but I will accept patches and post information you provide, such as
the address of a developer mailing list.