Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!psuvm.bitnet!cunyvm!ndsuvm1!ndsuvax!ncoverby From: ncoverby@ndsuvax.UUCP (Glen Overby) Newsgroups: comp.sources.d Subject: Re: "Archive-name:" proposed change Keywords: multiple part postings Message-ID: <2464@ndsuvax.UUCP> Date: 24 Mar 89 23:18:22 GMT References: <780@usl.usl.edu> Reply-To: ncoverby@ndsuvax.UUCP (Glen Overby) Organization: North Dakota State University, Fargo Lines: 44 In article <780@usl.usl.edu> pml@usl.usl.edu (Patrick Landry) writes: >I am currently putting together a script to save >postings to the sources and binaries groups currently >using the extra header lines a la comp.sources.unix. [ ... ] >My proposal would be to add a number to the end of the >Archive-naem header such as > Archive-name: foo/bar/Part01of25 >If articles were stored using these archive names an ls >in the directory would indicate whether all parts were there. >The only other option I have come up with is > Archive-name: foo/bar/Part25.final >on the last part. Personally I don't care for this as much. If I'm interpreting your proposal correctly, all you're changing is the last filename element of the Archive-Name line. This might be nice, but I get the feeling that it would make things a bit more cluttered. I have a program which will parse the message header and part of the body for recognisable strings, such as the standard header lines, Rich's extra header-style lines, uudecode lines, several types of shell archives, etc. I find the current Archive-Name to work extremely well. I assume there are many others like me who run such programs; If the Archive-Name field is going to be significantly modified, an advanced warning should be posted so that those of us with automatic news savers can update our programs. As an alternative to modifying the current Archive-Name line, I would like to propose an additional header-style line, "Archive-Part", of the format: Archive-Part: NN of TT where NN is the part number and TT is the total number of archives. It could also be extended for patches, but that might be overkill. A reasonably smart program could then maintain a database of what programs have been received in full, and possibly combine and decode (binary) or un-archive (source) the distribution. If you want a program do save news, look at the "narc" program in comp.sources.unix (one of the past 3 volumes). I haven't looked at it too deeply, but it was a pretty nice program. You might not have to build your own wheel after all! -- Glen Overby uunet!ndsuvax!ncoverby (UUCP) ncoverby@ndsuvax (Bitnet)