[comp.sources.apple2] v01_ADM_8: Still more on archiving

jac@paul.rutgers.edu (Jonathan A. Chandross) (09/07/90)

Submitted-by: jac
Posting-number: Volume 1, Administrivia: 8

Two more postings on archive names.  I suspect that with these, all the
relevant issues have been hashed out and a decision should be made fairly


From: Chris Myers <chris@wugate.wustl.edu>

I've read the commentary going on in c.s.a2, and would like to point out
a couple of things:

1) If you don't like the organizational scheme, you can always change next
   time you start a new volume (they don't HAVE to be 100 or so files!).
   It never hurts, though, to standardize early.

[ This depends upon whether files are archived as volumes or not.  My
  feeling is that if somebody wants all the sources for Apple Pascal,
  for example, she shouldn't have to go digging through each volume
  looking for all the relevant files. ]
2) Having the version number handy is valuable, but it may not be necessary
   to put it in the directory name.  Why not post a file whose name AND
   contents indicates the current version number along with the source:


[ I think that a read-me file is a much better way to go.  Why keep
  adding all this version number stuff unnecessarily.  This scheme
  also adds an additional directory level. ]

3) Don't go too deep with directories, since an archive is likely to place
   the comp.sources.apple2 tree several levels down to start with.  A
   path of /archive/usenet/comp.sources.apple2/volume10/games/foobaz/part01.Z
   is plenty long enough and is a real example of what will be found
   when retrieving files from wuarchive.

[ I agree; that's why I don't like (2) ]

4) Keeping the size of individual files down to 50 or 60 kbytes is a good
   idea since some sites will silently eat larger files.  Running the
   source tree of the submitted package through an archiver that spits
   out a single large binary file is OK -- you can then encode the file
   in ASCII and split it into smaller pieces.

[ Well, sort of.  If one piece gets garbled you have to get the new
  piece and concatenate all the other pieces together.  Unpacking a
  bit at a time is probably more civilized. This is why people package
  up multiple files separately, instead of having a monster shar file
  which has to be constructed from the pieces. ]

   Posting the source unencoded is safe when it is passing through most
   of USENET, but when it is gatewayed onto other networks (such as
   BITNET) there are a lot of things that can go wrong: long lines will
   be wrapped, the file may be translated to EBCDIC and then back to
   ASCII (destroying some of the less usual ASCII characters in the
   process), etc.

[ Too bad.  Bitnet people should fix their gateway code.  This has
  been debated before on comp.sources.d and the conclusion was that
  it was a Bitnet problem. ]

5) Since the Apple II computers apparently have a lot of dissimilar
   programming environments, you should indicate in the header of the
   first part of each package what it will run under.  Trying to
   separate these by putting them in a different directory tree is
   going to be much more hassle than it's worth.

[ Yes, but the objection has been raised that people might download
  something they can't use.  My inclination is to have a decent
  read-me somewhere that describes what each package does, the
  current version number, and what maching it runs on. ]


From: Bruce Kahn <bkahn@archive.webo.dg.com>

|> Posting-number: Volume 1, Administrivia: 7
|> From: timothy l meekins <meekins@cis.ohio-state.edu>
|> What we cannot forget when archiving source, is to allow a hierarchical
|> file structure. For instance, I recently released the source code to a 
|> graphics demo I wrote. This source code *had* to be placed within separate
|> subdirectories, and at the same time be archived all together. The Source
|> Code Sampler from Apple also uses directory nesting. How about something
|> similar to Apple-Single, but with 7-bit bytes.

  If we adopt something along the lines of shar/unshar then this wont be 
an issue.  Simply save the archive parts in a directory with a descriptive
name (along the path to the parts that is; more below).

|> I would also suggest that in *all* postings that the program version number
|> be given. Some programs have many versions floating around, and many
|> archive sites simply don't use the version numbers, thus requiring one to
|> download and unpack the entire program to see if it's a new version or an
|> older version.
|> [Much stuff removed...]

[my comments follow]
|>  If we adopt Larry Virden's suggestion (+) of categorizing by machine,
|>  we'd end up with archive names like:
|> 	games/apple2e/aliens/v1.0/aliens.part1
|> 		...
|> 	games/apple2e/aliens/v1.0/aliens.part6
|>  This doesn't actually look so bad, but it is a bit verbose.

  True and it makes life more complicated in that you have to look around
according to machine type AND category.  Doesnt save much if you just use
either an archive-wide index with an indicator as to which machines the
archive supports (ie G = GS, e = //e, E= enhanced //e, or whatever) or what
many other archives use, a README file w/each archive (or at least category).
The README file could be part of the original submission (a requirement for
submission ?) and all the maintainer would have to do is just copy it out
and put it in the directory w/the posting.
  IMHO, just having something like:
seems simple enough and gives anyone looking at the archive the chance to
get the README file first before taking time do d/l the package as well as
find out what is available in the entire archive under the category unix.
The size of the README should not be that great (maybe a couple thousand
bytes max, typically less) and the Index would be a great help in looking
around the archive.  It also allows you to put postings that support more
than one machine in just one place...

[ Exactly.  Put it all in the READ.ME.  Tells you what it is, and what it
  runs on. Simple programs would not have their own entry, but would have
  one in the READ.ME? ]


To get something posted to comp.sources.apple2, send it to:
	Internet: jac@paul.rutgers.edu
	UUCP: rutgers!paul.rutgers.edu!jac

Jonathan A. Chandross
Internet: jac@paul.rutgers.edu
UUCP: rutgers!paul.rutgers.edu!jac