[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Apple2 archive at grind.isca.uiowa.edu



In article <282gdd$hp4@pith.uoregon.edu>,
Neil Parker <nparker@cie.uoregon.edu> wrote:

>For whatever it's worth, my own opinion on this issue is that suffixes are
>the best way to go.  If the file name has a suffix on it, then the user can
>tell at a glance how it needs to be downloaded...if I see ".shk" on the end
>of a file name, I can tell immediately that I need to type "binary" before
>FTPing it to my machine.  When I don't see a suffix, I have to guess.
>
	[ some stuff deleted ]
>
>Properly maintained, index files would be a very useful tool for
>eliminating the mystery over the contents of a not-very-descriptively-
>named file.  You need, though, to find somebody who's willing to commit
>some time to making sure the index files are kept up-to-date.

This pretty much sums it up. Whatever standards we DO decide on will be
completely meaningless if the archive maintainer doesn't adhere to them, and
keeps a sloppy archive. If there is just a mis-matched smattering of
different types, with no suffixes at all, there will be much wasted time by
many people.

And even if there is only one kind of file found in the archive (or in a
particular archive), there is STILL a use for three-letter suffixes. Consider
this: usually when I go searching for something in the archives, I will
download what I see that may be of use to me in several different archives.
Now, without suffixes, when I'm done, there are just a bunch of files from
many different archives. These could all be different, even though on
such-and-such archive, we ALWAYS use xxx type of files.

Take a look at DMZ's implementation of cco.caltech.edu. He has
changed virtually everything into .shk, AND maintains the suffix. He also
seems to check each and every item that comes into the uploads directory
before placing it in it's proper place, so the problem of bad files,
mis-labeled ones, etc. is nipped in the bud. (At least he was doing this when
he'd first taken over cco. I haven't really checked it out lately.)

And with this type of high-intensity maintenance of an archive, it would be
pretty simple for the maintainer to type up a paragraph describing a file.
About the only complaints I've noticed of DMZ's upkeeping practices are that
he uses _HIS_ better judgement to see what stays and what doesn't, due to
space limitations, which are not always the same as someone elses better
judgement. The other complaint I've seen is that a few people are unable to
download binary files. His decision to go with .shk is also a space
limitation, however, since .shk tend to take up much less room than .bsc or
whatever ascii files.

What I guess I'm trying to say is, we should use cco as a basis to build on
for the grind archive. Now, with that said, please continue the friendly
discussion on this subject. ;-)

Tim Savage	|	ksavage@ub.d.umn.edu		|	A2 Forever!