bryce@eris.berkeley.edu (Bryce Nesbitt) (03/03/88)
In article <> farren@gethen.UUCP (Michael J. Farren) writes: > >I am going to urge a NO vote on comp.binaries.hypercard. My reasons? >Basically, two. First, the volume... >Second, the limited applicability of this... > >If you take this as a condemnation of binary groups in general, you're >probably right. It would be very intersting to see how many times computer-specific binary messages are actually downloaded by someone.* I strongly suspect is is often a much smaller number than the magic "100 message - mail vs. net breakeven point". Perhaphs what is needed is a demand based system.** A reader sees a *full* description of the binary, and presses a key that means "I want a copy". This message is stored by rn, and transmitted upstream next time news is processed.*** The delay is unimportant for most binaries, (especially long binaries).**** 800K of hypercard stack is not a trivial thing to transmit to the entire world. * Yes, I am aware how impossible this would be under the current system. ** Yes I know that it would be much work to add. Also I know, but do not like, the fact that not all sites run the same software, and that may sites run old software. (-: I'll be more would upgrade if the new system was made incompatible :-). *** A backchannel would be great for reader-based "ratings" on the quality of articles. **** Yes, there is justification for this. The only urgent binaries are likely to be patches. Patches are usually small. |\_/| . ACK!, NAK!, EOT!, SOH! {O_o} . Bryce Nesbitt (") BIX: mleeds (temporarily) U USENET: bryce@eris.berkeley.EDU -or- ucbvax!eris!bryce
dan@maccs.UUCP (Dan Trottier) (03/06/88)
In article <7351@agate.BERKELEY.EDU> bryce@eris.berkeley.edu (Bryce Nesbitt) writes: >In article <> farren@gethen.UUCP (Michael J. Farren) writes: >> >>If you take this as a condemnation of binary groups in general, you're >>probably right. > > >Perhaphs what is needed is a demand based system.** A reader sees a >*full* description of the binary, and presses a key that means >"I want a copy". This message is stored by rn, and transmitted >upstream next time news is processed.*** The delay is unimportant >for most binaries, (especially long binaries).**** > >* Yes, I am aware how impossible this would be under the current system. Not really! See "MY PROPOSAL..." below. >** Yes I know that it would be much work to add. Also I know, but do >not like, the fact that not all sites run the same software, and that >may sites run old software. (-: I'll be more would upgrade if the new >system was made incompatible :-). Then don't add it to the news system. Build around it. >*** A backchannel would be great for reader-based "ratings" on the >quality of articles. This is called a "reply" to the sender. You don't have to post your feelings to the net. You just have to send them via mail to the originator of the article. >**** Yes, there is justification for this. The only urgent binaries >are likely to be patches. Patches are usually small. Well not just patches but anything that you know many many people want! Like Patch (Thanks Larry). MY PROPOSAL FOR REDUCED NET TRAFFIC ----------------------------------- There exist ways to do what you mention without having to add/modify the news reader programs in existance. There seem to be several sites that have specialized mail servers that send files upon receipt of a request through the mail. Sites (people) that moderate binary and some source groups could install these servers. Instead of posting the sources/binaries you post a description of the package in more detail than presently and have interested people send for the package via mail. The *problem* with this approach is that the load on the machine where the mail server resides will be much greater. As it stands now, a moderator posts the package and it leaves his site once and only once (well almost only once! :-) The network then distributes the files to all the sites. This is fine when the interest is high enough and sites are willing to accept the *costs*. How many people (sites) would moderate these groups if it meant that their system would have to respond to user requests for the software? What would the uplinks for these sites have to say about the increased traffic? Perhaps posted software should be deposited on central HUB sites (like uunet) where people can send their requests or use annonymous UUCP and FTP to grab the files? The administrators of the moderating or HUB sites could then monitor the demand for the software and if demand was high enough it could then be posted throughout the net. There are many possibilities, many are valid some not so valid. Let me know what you think about this. If the response is high enough I'll try to summarize. We WILL have to find a way to reduce the traffic before to long the way things are going. Looking towards better quality and less quantity news! -- A.I. - is a three toed sloth! | ...!uunet!mnetor!maccs!dan -- Official scrabble players dictionary -- | dan@mcmaster.BITNET