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 soon. -------------------------------------------------------------------------------- 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: games/foobaz/VERSION-1.012y73 [ 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: unix/Index.unix ... unix/ascii2ps/README unix/ascii2ps/a2s.part1 ... unix/ascii2ps/a2s.part5 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