Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!lisboa!windemut
From: windemut@lisboa.tmc.edu (Andreas Windemuth)
Newsgroups: comp.sys.next
Subject: Re: news reader --- more
Message-ID: <1990Dec5.012941.23554@ux1.cso.uiuc.edu>
Date: 5 Dec 90 01:29:41 GMT
References: <4198@media-lab.MEDIA.MIT.EDU> <337@heaven.woodside.ca.us> <15422@cs.utexas.edu>
Sender: news@ux1.cso.uiuc.edu (News)
Organization: Theoretical Biophysics, University of Illinois, Urbana
Lines: 85

I'd like to comment on the "attachments or not" subject.
I think it should be done for two reasons:

    1. most of the (though valid) objections can be adressed (see below)

    2. It will have to be done sometimes in the future, why not start now?


In article <15422@cs.utexas.edu> osborn@cs.utexas.edu (John Howard Osborn) writes:
>
>I'd like to explain why I think this is a really great idea that we
>shouldn't do.
>
>- It will require people to use your newsreader/poster.  There will probably
>  be lots of people who want/need a feature that your newsreader doesn't
>  provide and they'll be out in the cold.  (For example, note the abundance
>  of plain-text newsreaders, nn, rn, vnews, readnews, gnu-news, and so on.
>  Obviously, lots of people want lots of different features.)

With a mixed or indexed scheme as many people have described it 
this problem is fixed. People without an adequate newsreader
don't get the rtf/attachment part, but they wouldn't get 
that either if no newsreader supported it.

>
>- Moreover, people without NeXT systems are out in the cold.  I would wager
>  that a great majority of comp.sys.next readers (including myself) don't
>  yet own a NeXT or don't use it directly on the net.  I dial from home
>  into my university's news machine, so I would be out in the cold.

You would be no more in the cold than you are now.
Same point.

>
>- Any of the proposed workarounds to this problem are ugly.  Some of them
>  require posting every message twice (RTF version, plain version) which is
>  a really nasty waste of bandwidth.  At least one of those methods
>  suggests posting a plain version at the top of a message and an RTF
>  (or even tar'ed, compressed, uuencoded) section at the bottom.
>  Nobody, not even me, wants to be forced to wait for a section of
>  uuencoded data to start and then hit 'n' a hundred or so times a day.
>  (And wait until comp.sys.next gets as big as comp.sys.mac before the split.)
>  Moreover, the plain-text version of the message would lose information.

True, it is an additional overhead to type 'n' after a ^L
instead of a return at the end of the message. I think it's
worth it, though.

>
>- Serious bandwidth considerations.  Until ISDN hits big, a VERY large
>  percentage of the nodes out there feed through 1200 or 2400 baud modems.
>  Even with a trailblazer bandwidth can be a problem.  When people start
>  posting voice messages and application attachments the size of comp.sys.next
>  would grow tremendously, making it difficult for those sites to carry.
>  (Just wait for the digitized-audio .signature file.  Gads.)

First, only people with NeXTs would post the larger, composite
messages. Second, as others have pointed out, sites with bandwith
problems could decide to strip the attachment part from messages.
Still, this is probably the greatest disadvantage of the system.

>
>- It is important for people without NeXT systems to read/write to
>  comp.sys.next.  Admittedly, the number of "Should I buy a NeXTstation?"
>  and "Does it run X?" questions could be reduced some, but valuable
>  contributions are made by these people.  Besides, what if you wanted to
>  read comp.sys.next before decided to purchase a machine?  What then?
>  NeXT is out a sale, and you (as a possible developer) are out a possible
>  sale, and the market for NeXT doesn't grow a little bit, as it should.

Of course, the text part of messages has to be readable on any newsreader.
Given that, and the fact that all those beginner's questions
would come without attachments, helping with the bandwidth problem,
I don't see the point anymore.

>
>I still think the software should be written, because it would be really
>great for internal (to a company, say) newsgroups and a really good
>project, too.  But, it shouldn't be the primary method of using comp.sys.next.

Well, no, not primary. Just as an additional feature for those
who have the capability. (Maybe it would even enhance the sales
of NeXTs? :-)

Andreas Windemuth