commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From steve cohen <sco...@javactivity.org>
Subject Re: [net] SYST/FTPClient.getSystemName()
Date Tue, 30 Dec 2003 18:57:27 GMT
On Tuesday 30 December 2003 12:13 pm, Jeffrey D. Brekke wrote:
> Two additional ideas:
>
> 1) What about defining one parser implementation, and having the regular
> expressions vary based on system?

This has come up before.  I don't think it can work.  The regex can break the 
input into groups, but there still needs to be CODE that recognizes that the 
third group represents the month and the fourth the year, etc.  If regular 
expressions provided a way to NAME or otherwise identify the groups, we might 
be able to rock and roll but I don't believe that ORO provides this and 
neither does java 1.4's java.util.regex.  I think I maybe once saw something 
like this in Perl or Python, but not in anything we can use here.  But that's 
what it would take.  Lacking that, CODE is necessary to provide the necessary 
CONTEXTUAL information needed to parse a regex into a data structure such as 
FTPFile.

On the other hand, it's just a mapping.  What is expressed as code such as 
this:

            String typeStr = group(1);
            String hardLinkCount = group(15);
            String usr = group(16);
            String grp = group(17);
            String filesize = group(18);
            String mo = group(19);
            String da = group(20);
            String yr = group(22);
            String hr = group(23);
            String min = group(24);
            String name = group(25);
            String endtoken = group(26);

could be stored in some sort of table that is associated with the regex.  But 
there are still problems with other bits of logic that live over and above 
regexes, such as the different parsing of dates based on whether the date 
falls within the current year or a past year (embodied in code as "if" 
statements), that make this problematical.

So I think the effort level here is much more than you are imagining.

>
> 2) Use host name/ip address to also select the parser/RE.  I was
> thinking then one could have a properties file or something setup with
> the parser to use ( off the top of my head, not much thought into this
> yet):
>
> default=UNIX
> VMS=[fq parser classname] or [ regular expression ]
> ...
> qdsvms.qgraph.com=VMS
> 192.1681.1.1=EnterpriseUnix
>
> Then if there is no specific host/ip listing, default to the system
> name mapping, else the default parser ( which could also be customized
> )?

This idea seems worthy of more attention.  I think it holds promise.
>
> >>>>> On Tue, 30 Dec 2003 12:13:36 -0600, steve cohen
> >>>>> <scohen@javactivity.org> said:
> >
> > Well, it sounds like only OS2 and Enterprise Unix are problematical.
> > I Googled "OS2 FTP" and I can't find a single publicly accessible
> > FTP site that runs OS2.  I did find this page:
> >
> > http://www.sentex.net/kwos2cug/os2-ftp.html
> >
> > which lists dozens of ftp sites RELATED to OS2.  The majority of
> > them are defunct and those that are still live are running on unix
> > servers.  But for now, it will be fine to use the "OS/2" key.  If
> > anyone can provide more accurate information, please send it on and
> > we'll be happy to include it.
> >
> > As for "Enterprise Unix", since it doesn't seem to identify itself
> > as anything different from regular Unix, we won't be able to provide
> > auto-detection.
> >
> > What I am envisioning now is a factory method like this:
> >
> > public static FTPFileEntryParser createFileEntryParser(String key);
> >
> > where key could be either one of the known strings ("UNIX", "OS/2",
> > "Windows", or "VMS") or else a fully qualified class name of a class
> > that implements FTPFileEntryParser (to accomodate Enterprise Unix
> > and any user-written parsers that may be out there).  If there are
> > other versions of these keys in existence, they, too can be allowed;
> > we can have a many to one mapping between keys and parsers.
> >
> > This API would be exposed to outside clients such as Ant.  The ant
> > <ftp> task can be rewritten to have an additional attribute called,
> > say, "servertype" that the user can supply and the code rewritten to
> > instantiate this parser and use it.  This method can also be the
> > guts behind an autodetection scheme yet to be written.
> >
> > On Tuesday 30 December 2003 08:58 am, Jeffrey D. Brekke wrote:
> >> For OS2 we check if the string OS/2 is present.  For NT we check if
> >> the string Windows is present.  For VMS we check if the string VMS
> >> is present.
> >>
> >> This way we don't have to mess with version numbers and stuff.  The
> >> actual returns that I can verify are:
> >>
> >> AIX v5.1L: UNIX Type: L8 Version: BSD-44 Linux (Redhat/wu): UNIX
> >> Type: L8 OpenVMS: VMS OpenVMS V7.1 on node XXXXXX.  Windows
> >> NT/2000: Windows_NT version 4.0 Windows_NT Windows_NT version 5.0
> >>
> >> The Enterprise for UNIX 1.2.05 Secure FTP server we've encountered
> >> also reports: UNIX Type: L8 and does not have a normal unix
> >> listing.  That is why we needed to write a special parser for that
> >> one.
> >>
> >> We no longer have OS/2 servers available.
> >>
> >> >>>>> On Tue, 30 Dec 2003 07:16:05 -0600, steve cohen >>>>>
> >>
> >> <scohen@javactivity.org> said:
> >> > [originally posted in a slightly different form on commons-dev,
> >>
> >> now > cross-posting to commons-user]
> >>
> >> > I am beginning the work of tying the selection of a specific >
> >>
> >> FTPFileEntryParser in commons-net to the output of the SYST command
> >>
> >> > on that system.  (getSystemName() is a wrapper around SYST).  The
> >> > goal of this is to enable clients of this code (such as Ant) to
> >>
> >> be > able to select specific parsers without tying themselves too
> >> closely > to the internals of commons-net, i.e., knowing the
> >> package names and > class names of each of the parsers.
> >>
> >> > To that end, I would like to compile a list of
> >>
> >> SYST/getSystemName() > outputs on each of the different system
> >> types, so we can code a > mapping for this.  Eventually, it may
> >> even lead to an auto-detect > functionality.
> >>
> >> > I know that a default unix FTP server will return "UNIX".  Will >
> >>
> >> those who use this code on other systems be so kind as to help me >
> >> fill in this table?
> >>
> >> > Commons-Net Parser Type that Return Value succesfully parses
> >>
> >> entries > from getSystemName() ---------------------------- >
> >> -------------------- UnixFTPEntryParser UNIX NTFTPEntryParser ?  >
> >> OS2FTPEntryParser ?  EnterpriseUnixFTPEntryParser ?  >
> >> VMSFTPEntryParser ?
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >>
> >> > 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


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


Mime
View raw message