🚀 go-pugleaf

<excerpt>
In article 1991Jun25.063045.22031@mel.dit.csiro.au 
	smart@mel.dit.csiro.au (Bob Smart) writes:
   There are two ways of supporting broadcast services: government
   funding (the BBC) and advertising (the American way). Why not end
   each comp.archives posting with

     Comp.archives is brought to you by the Big Blue Computer Company
     -- number 1 in information processing.
</excerpt> <par>
Sure, it could even be topical by the origins of the group involved; I
think I'd put it in the verification section like so.  Tags are
prototypes right now, and you'll excuse the blatant advertising, which
is included without anyone's permission.  (The archive-normal-form is
also a prototype worth looking at.)
</par> <par>
Newsreaders could be configured to ignore the advertising, which
should make this sort of use completely consistent with most usenet
guidelines.  Advertising is not offensive if it is unobtrusive and if 
can be easily ignored, either if it is separated into its own
newsgroup (comp.newprod) or perhaps it it's explicitly tagged.
</par>
<verification>
<kw>
ups	debugger saber c dbx adb gdb x11 sunview ups-2.31
</kw>
<archive-normal-form>
19910520.2205 ftp export.lcs.mit.edu /contrib ups-2.31.tar.Z 963435
19910520.2237 ftp export.lcs.mit.edu /contrib ups-2.31.README 9758
19910528.1254 ftp ftp.uu.net /tmp ups-song.ms 1237
19910529.0944 ftp ftp.uu.net /tmp ups-song.au 1456032
</archive-normal-form>
<ad>
Saber C -- The Complete Programming Environment for UNIX Workstations
Saber Software Inc, saber@saber.com
</ad>
<snappy-quote>
Those who have tried (ups) claim it's the next-best thing to Saber C.
-- Mark Moraes, comp.archives article 1991Jun3.231125.11963@ox.com
</snappy-quote>
<ad> Contact info@msen.com for information and rates. </ad>
</verification>

<sig>
Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com
<ad>
This message brought to you by the letters C and E and the number 3.
</ad>
</sig>

Let me explain and justify this format for recording archive
information, in the hope that it'll get wide use.  I'll be converting
the "MSEN Archive Service file verification" section of comp.archives
postings to this format so I want to get it right.

I believe I've sketched out something which would let you verify every
file that's available for anonymous FTP or semi-public FTP that's out
there; 

Here's a sample example.

19910520220500 f export.lcs.mit.edu /contrib ups-2.31.tar.Z 963435 ftp,30
19910520223700 f export.lcs.mit.edu /contrib ups-2.31.README 9758 ftp,30
19910528125400 f ftp.uu.net /tmp ups-song.ms 1237 ftp,21
19910529094400 f ftp.uu.net /tmp ups-song.au 1456032 ftp,21
19910530012300 d msen.com /debug/ups emv,case
19910624112800 w prep.ai.mit.edu /pub/gnu gawk* bug-gnu-utils
19910411185329 f nis.nsf.net,anonymous,guest . $read.me 1024 postmaster

$date f $site $dir $file $size $owner
$date w $site $dir $wildcard $owner
$date d $site $dir $owner

here's what the fields are.

19910520220500	$date: Date in ISO 3307 format (YYYYMMDDhhmmss[.xxxxxx]) 
		Sorts easily, easy to parse, microsecond resolution,
		will be used in NNTP2.
(d,f,w)		$type: directory, file, or wildcard specification.
		Directories have ($site, $dir, @owner).
		Wildcards   have ($site, $dir, $wildcard, @owner).
		Files       have ($site, $dir, $file, $size, @owner).
		Any other type can be added as long as suitable
		definitions for the following fields can be provided.
export.lcs.mit.edu	$site: System name.
		The default assumption is login with user "anonymous", any
		password acceptable; the entry for nis.nsf.net shows
		a situation where there's something different from the default
		that's needed; in that case it's interpreted as
		  ($site, $user, $pass)
	 	or even
		  ($site, $user, $pass, $acct)
XXX should ascii,binary be in here somewhere too?
XXX should some notion of explicit file types be here?

There are three sorts of things to describe, files, directories, and
wildcard specifications.  Files are operated on with the DIR, GET, and
MGET commands.  Directories are operated on with the CD and DIR
commands.  Wildcards are operated on with the DIR and MGET commands.

gawk*		$wildcard: wildcard file specification.  Specified according
		to local host conventions.  The $date variable for this
		should be set to the latest change date for the files
		that match the wildcard file specification.
/contrib	$dir: Directory.  cd to this directory.  In the special
		case where no cd command needs to be (or should not
		be) issued, treat "." as a no op.
ups-song.au	$file: File name.  
1456032		$size: File size, in bytes, when properly transferred to
		a different machine.  Systems which report sizes in blocks
		need to translate.
emv,case	$owner: comma-separated list of owners.  First one should
		also be a mail address (e.g. emv@archive.msen.com).  The
		rest can be group names or any other key words, tags,
		or identifiers which you might choose to use, or names
		of mail addresses.
XXX this is pretty wide open....

-- 
Edward Vielmetti, MSEN Inc. 	moderator, comp.archives 	emv@msen.com

In article <EMV.91Jun25175321@bronte.aa.ox.com> emv@msen.com (Ed Vielmetti) writes:
> 19910520220500 f export.lcs.mit.edu /contrib ups-2.31.tar.Z 963435 ftp,30

Methinks

  19910520220500 f export.lcs.mit.edu:contrib/ups-2.31.tar.Z 963435 ftp,30

is both more readable and more accurate. Your separation between
``directory'' and ``file'' is a mistake, because some operating systems
can express neither the null directory nor more than one directory in a
single command. It's much more logical to have a composite filename,
where each component before a slash means ``change directory to this.''
foo/bar/blah means ``cd foo, then cd bar, then get blah.'' Of course,
you can pile all the cd's into one if you're talking to a UNIX server,
but automated programs shouldn't depend on knowing the remote system
type. It's probably necessary to add quoting ("/", perhaps), for cases
like the Kerberos distribution where you simply have to combine two cd's
into one or you hit a wall.

You had better take into account that a lot of people don't have DNS.
Also, some systems don't have meaningful dates or owners but still
support ftp.

> 19910530012300 d msen.com /debug/ups emv,case
  19910530012300 d msen.com:debug/ups/ emv,case

The blank filename means that you're referring to the directory.

> 19910624112800 w prep.ai.mit.edu /pub/gnu gawk* bug-gnu-utils
  19910624112800 w prep.ai.mit.edu:pub/gnu/gawk* bug-gnu-utils

> XXX should ascii,binary be in here somewhere too?

Probably. Maybe introduce an ``E'' type, just like f but for EBCDIC,
meaning that you shouldn't use binary. (I'm half serious.)

---Dan

In article <1991Jun25.063045.22031@mel.dit.csiro.au> smart@mel.dit.csiro.au (Bob Smart) writes:
>There are two ways of supporting broadcast services: government
>funding (the BBC) and advertising (the American way). Why not end
>each comp.archives posting with

Isn't there a third way, paid for by people who actually want the service,
eg Cable TV.


Somebody who HAS to pay for the BBC.
-- 
  Alan Barclay
  iT                                |        E-mail : alan@ukpoit.uucp
  Barker Lane                       |        BANG-STYLE : .....!ukc!ukpoit!alan
  CHESTERFIELD S40 1DY              |        VOICE : +44 246 214241

In article <17493.Jun2607.22.3191@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
   Methinks

     19910520220500 f export.lcs.mit.edu:contrib/ups-2.31.tar.Z 963435 ftp,30

   is both more readable and more accurate. Your separation between
   ``directory'' and ``file'' is a mistake, because some operating systems
   can express neither the null directory nor more than one directory in a
   single command. It's much more logical to have a composite filename,

However, FTP is oriented to "directory and file name" access -- you CD
to a directory, then you GET a file.  Thus, it's best to have two
fields -- the first one is "the argument to give to CD" and the second
is "the argument to give to GET".

Logically, it's still losing, but it corresponds more closely with the
model FTP presents.

Dale Worley		Compass, Inc.			worley@compass.com
--
The best way to demand something unreasonable is to call it a "freedom".

In article <EMV.91Jun25175321@bronte.aa.ox.com> emv@msen.com 
(Ed Vielmetti) writes:

>19910411185329 f nis.nsf.net,anonymous,guest . $read.me 1024 postmaster
>
>$date f $site $dir $file $size $owner
>$date w $site $dir $wildcard $owner
>$date d $site $dir $owner

A couple of suggestions:

1. The rcp format host:directory/file is well established and marginally
shorter. It extends to user@host:directory/file and you could add
a convention like user,password@host:directory/file (as well as allowing
wildcards in file or ending at / for a directory, which makes the
"f,w,d" type field redundant though it might as well stay).

2. I don't know if "owner" is really much use. If it is, then "group"
would probably be equally relevant.

3. (More important) Using space as the delimiter between fields
does not allow for file and directory names that include spaces
(common with Mac software). In modifying the Mark Moraes filters
that you sent me I got around this by using TAB to separate the
site:directory/file field from size and date fields. For comp.archives
you would need something like "" around any field that does contain
a space (usually omitted since the large majority don't contain
a space, but at least allow for it).

This may seem unimportant from current experience with anonymous
ftp archives, but tools developed will also be applied to archives
that are available from non-anonymous ftp and the way things are
going all files on any kind of machine are going to be mounted on
the net somewhere or other.

Also some efforts at classifying files in ftp archives may rely
on linking them to long descriptive directory names (with blanks).
e.g. The one line descriptions available from dls could simply
be linked as alternative names in another directory.

--
Opinions disclaimed (Authoritative answer from opinion server)
Header reply address wrong. Use cmf851@csc2.anu.edu.au

In <17493.Jun2607.22.3191@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:

>  19910520220500 f export.lcs.mit.edu:contrib/ups-2.31.tar.Z 963435 ftp,30

>is both more readable and more accurate. Your separation between
>``directory'' and ``file'' is a mistake, because some operating systems
>can express neither the null directory nor more than one directory in a
>single command. It's much more logical to have a composite filename,
>where each component before a slash means ``change directory to this.''


Except you have the problem that many OSes use a different separator
character than /, and allow slashes in file names (most commonly used for
putting dates in filenames...).

Then there are OSes that don't have 'directories', they have 'disk packs',
and then there are the hybrids (e.g. VMS). Every designer seems to want to
create yet another incompatible syntax for filesystems...

The clearest way to handle all the different variations out there is to keep
directory and file information separate.

Remember, all the world's not UNIX.

--
C. Harald Koch  VE3TLA                Alias Research, Inc., Toronto ON Canada
Internet:    chk@alias.com      chk@gpu.utcs.toronto.edu      chk@chk.mef.org
"I think you curdled my Pepsi!"-Gerry Smit, in response to sickening cuteness