brad@looking.UUCP (Brad Templeton) (08/27/88)
It's becoming clearer and clearer that the method we use of splitting binaries into 15 parts and sending them over the net is a colossal waste of resources. We get dropped files - different ones in different places, and constant requests for reposting. NETNEWS IS NOT A GOOD WAY TO DISTRIBUTE BINARIES. Some might argue the net isn't a good way, but if it is going to do it, let's at least do it right. I believe binary files should be sent in single chunks. All or nothing. If the whole file doesn't make it, then none of it should be sent. The elegant way to do this would be to make sure netnews had the capability to send binary files up to, say 700K, in length. Since this is not going to happen, I propose to write a simple propagation program for binary files. Called "rbin" it would be an additional uux command. It would take binaries and store them in a spool directory. It would then do a simple rebroadcast down the binary net. Very limited header processing to avoid loops and classify types would be required. (Loops would not exist in the binary net, in theory, but that may be tough to spot in practice.) A simple use of the "find" command in the cron would expire the binaries. Only moderators would post to the binary net. The binary net would transmit binaries. No uuencoding. Just ARC(TM)ed, compressed tar or raw binaries. Simple and efficient. Should take a few hours to write, if people are willing to set it up. ARC is a TM of SEA, Inc. -- Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473
ncoverby@ndsuvax.UUCP (Glen Overby) (08/28/88)
In article <1981@looking.UUCP> brad@looking.UUCP (Brad Templeton) writes: >NETNEWS IS NOT A GOOD WAY TO DISTRIBUTE BINARIES. I've felt the same way for a long time. The same (largely) goes for sources, too. But the sources groups seem to be managing better than binaries. I think that non-uucp forms of distribution should be supported from the beginning -- remember, much of the current news traffic is carried over NNTP and that translates to INTERNET. It won't be easy supporting some "foreign" networks (read "Bitnet"). > [ ... ] Very limited header processing >to avoid loops and classify types would be required. (Loops would not >exist in the binary net, in theory, but that may be tough to spot in >practice.) First of all, how exactly are you going to distinguish header from body? Will one empty \n be enough? After all, you won't have one of the most advanced AI systems in existance (the Human) to interpret ---CUT HERE--- lines. Some form of header will always be needed to indicate what group (or were you going to make that a parameter to rbin?), encoding type (you've already mentioned several; how do those of us on the recieving end of things figure out which was used? Gotta be a header). I disagree with your theory about loops not existing in the binary net. Not having redundant feeds has, in the past been very devastating for certain areas; newsaholics in Minneapolis will remember stolaf, Texas will remember killer. Redundancy is good, but it comes with a price (another phone bill). >A simple use of the "find" command in the cron would expire the binaries. I await your implimentation of "find" for VMS, VM/CMS, DOS, OS/2 and TOPS. Get my drift? Basing your transport mechanism on Unix utilities will leave those not on Unix high and try. And they're not gonna like it! Accomodate them from the start and there shouldn't be as many growing pains. >Only moderators would post to the binary net. and Bob Webber :-) This "binary network" would also solve the emotional problem many people have about having binaries on Usenet. The binary groups would be split into a separate hierarchy due to their transport technique. It might be better to ask the News 3.0 crew about adding 8-bit support to their programs rather than completely re-inventing the wheel. After all, it might not be easy re-implimenting the line-eater :-) -- Glen Overby ncoverby@plains.nodak.edu, uunet!ndsuvax!ncoverby ncoverby@ndsuvax (Bitnet)