Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2E0ED.5D812FDA"
Subject: [NET] "Proposal" section added to main stem
Date: Sun, 2 Mar 2003 12:56:00 -0600
Message-ID: <D466FBEAA19E7E408BE3FAAC6EEB5676023FF666@utah.ignitemedia.com>
Thread-Topic: [NET] "Proposal" section added to main stem
Thread-Index: AcLg7UGx3VrlEsDpS/OhhVcom2y+rg==
From: "Steve Cohen" <SCohen@sportvision.com>
To: <commons-dev@jakarta.apache.org>

------_=_NextPart_001_01C2E0ED.5D812FDA
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

I have checked in code implementing the new FTPFileEntryParser system, =
that has been knocking around for close to a year.  This code basically =
allows an iterable list of ftp entries to created from which more =
expensive FTPFile objects are not created until they are needed.  It =
also checks in a number of regular-expression based parsers that =
implement this system.  This code, in a slightly different form, used to =
be found in=20

//jakarta-commons/net/ftp/ftp2

and then later in

//jakarta-commons/net/proposal/ftp2

but now it is moved to=20

//jakarta-commons/net/ftp.

This version is totally backward-compatible with the older system as =
were the earlier versions.   It is also well-integrated with the older =
system, which earlier versions were not.  That is to say that both are =
supported. =20

In the old system, after calls to log into the server

f=3DFTPClient();
f.connect(server)
f.login(username, password);

a list of files might be obtained by calling
f.listFiles(directory);

This will produce an array of FTPFile objects for the entire contents of =
directory which might get to be prohibitively large when scanning a =
large directory.

In the new system, it works like this:

f=3DFTPClient();
f.connect(server)
f.login(username, password);
FTPFileList list =3D createFTPFileList(directory, parser);
FTPFileIterator iter =3D list.iterator();

while (iter.hasNext()) {
    FTPFile[] files =3D iter.getNext(25);  // or whatever "page size" =
you want

    //do whatever you want with these files, display them, etc.
}

Unresolved issue:
There has been an issue raised with this system that it doesn't work on =
systems such as OpenVMS which sometimes send FTP entries that span line =
feeds.  This has not yet been fixed, but a means for fixing it has been =
implemented in this set of changes.  The FTPFileEntryParser interface =
now has this method:

    public String readNextEntry(BufferedReader reader) throws =
IOException;

This method is now called instead of BufferedReader.readLine() to get =
individual entries.  The default implementation simply delegates this =
call to BufferedReader.readLine().  Overriding this method in the =
VMSFTPEntryParser class to do the correct thing will solve this problem.

Steve Cohen
scohen@apache.org=09


------_=_NextPart_001_01C2E0ED.5D812FDA--