simsong@media-lab.MEDIA.MIT.EDU (Simson L. Garfinkel) (11/30/90)
some people sent me e-mail asking, "why write another news reader, if there already is one?" here's my response: I've seen William Shipley's News reader. In fact, I have the source code. Mine will be a little better for a few reasons: 1. It will *post*. 2. It will be configurable. 3. It will automatically build hypertext links between articles. 4. It will work with multiple news services: local news, Usenet news, New York Times, Thinking Machine's Wide Area Information System. In fact, you'll be able to plug in your own protocols. 5. Instead of taking the paradigm that you want to view *all of the news*, it takes the paradigm that you have a certain amount of time each day that you can spend on reading netnews, and it tries to show you the best articles to spend your time on. 6. In addition to reading news interactively, it will be able to typeset a "newspaper" with the articles that you think are important. 7. There will also be a connection machine interface, if you happen to have one of those. As I get parts of this news reader working, I'll release it, always with full source-code. Any suggestions for improvements will be happily taken, although not always implemented! I've posted this reply to the newsgroup because I think that other people might be interested and/or have suggestions... ================ So what's the word. Can I post rich text?
wjs@milton.u.washington.edu (William Jon Shipley) (11/30/90)
I'd like to mention at this point that I fully support Simon's new newsreader, and am in fact looking forward to it. I've had a bazillion ideas for News, but in truth as an undergrad I just don't have time to do them. Simon is a grad student doing his newsreader for his dissertation, and he can afford to take the time to really do it right. His ideas are a complete superset of mine: that is, he's thought up everything I had, and more. There will probably be a next and final release of News. It will hopefully support posting, printing, and saving articles. It will also hopefully not have the bizarre bugs. It will definitely support re-checking for new news at intervals, changing the icon to reflect this, and saving your .newsrc at intervals. It may support following threads. It'd be keen if it supported automatically marking some articles as extra important. (For example, I'd like to have everything written by Glenn Reid moved to the top of the newsgroup when I enter it.) -william shipley
jacob@gore.com (Jacob Gore) (12/03/90)
/ simsong@media-lab.MEDIA.MIT.EDU (Simson L. Garfinkel) / Nov 29, 1990 /
> 3. It will automatically build hypertext links between articles.
Nice.
What I would very much like to see is a threaded index:
1. All responses to a message are hidden behind the message that started
that thread.
2. The number of new responses is indicated for each thread. (Or, at
least, a flag indicating that there are new responses.)
3. (Optional) the number of responses (old and new) indicated for each
thread).
4. A user command to toggle between an index showing all threads, and one
showing only threads with new responses.
5. Clicking on a thread should display a list of all articles (original
message and responses) in that thread. The same user command as in #4
should toggle between an index showing all articles, and one showing only
new responses.
I've been using a major subset of what I describe below ever since I
started using Usenet. This is the major reason I'm still using Notes
instead of the various News B or News C systems, despite Notes' many other
limitations. The compressed index lets me keep up with 100 groups without
spending an enourmous amount of time on Usenet.
Jacob
--
Jacob Gore Jacob@Gore.Com boulder!gore!jacobglenn@heaven.woodside.ca.us (Glenn Reid) (12/03/90)
In article <4198@media-lab.MEDIA.MIT.EDU> simsong@media-lab.MEDIA.MIT.EDU (Simson L. Garfinkel) writes: >So what's the word. Can I post rich text? I think rich text is an excellent idea, but wait until lots of people have your mail reader before we start posting rich text, or nobody will like it. You should certainly build in the capability, in my opinion. If worst comes to worst, we could start comp.sys.next.rtf to handle the specially formatted messages, but I don't think it would come to that. It would be great to have a way to include files in postings, too, so people could drag them out of news into their directory structure.
glenn@heaven.woodside.ca.us (Glenn Reid) (12/04/90)
In article <11973@milton.u.washington.edu> wjs@milton.u.washington.edu (William Jon Shipley) writes: >It'd be keen if it supported automatically marking some articles as extra >important. (For example, I'd like to have everything written by Glenn >Reid moved to the top of the newsgroup when I enter it.) That's truly flattering, although I'm a little suspicious that your trailing .) looks a bit like a :) which looks like a :-) To tell you the truth, right after I read that, I went back to read as many of my postings as were still lurking about, and was embarrassed to note that most of them were the usual dreck. Sigh. But, properly chastised, I'll attempt to keep the truth up and the fiction to a minimum, although I can't promise to keep rank opinion from creeping in. Sure is fun, this USENET stuff. I've been posting half-truths, overblown opinions, and murky problem solutions for about ten or eleven years now, and it's amazing to note that "rn" and the network at large haven't improved one little bit. Kinda like UNIX, really. That's one of the reasons I think we all ought to start posting in RTF. ASCII is ASCII is ASCII, and we've lived with it since 1960-something. Time to stir the soup, and let people catch up if they have real computers and the will to do so. Also, RTF is a great acronym, as acronyms go, since it starts with the same thing that RTFM does, which about sums it up. Sorry, a bit of a content-free posting. But at least I didn't include the entire text of the quoted article or quote Bob Dylan or flame anybody :-) Glenn -- Glenn Reid RightBrain Software glenn@heaven.woodside.ca.us PostScript/NeXT developers ..{adobe,next}!heaven!glenn 415-851-1785
osborn@cs.utexas.edu (John Howard Osborn) (12/05/90)
In article <337@heaven.woodside.ca.us> glenn@heaven.woodside.ca.us (Glenn Reid) writes: >In article <4198@media-lab.MEDIA.MIT.EDU> simsong@media-lab.MEDIA.MIT.EDU (Simson L. Garfinkel) writes: > >>So what's the word. Can I post rich text? > >I think rich text is an excellent idea, but wait until lots of people have >your mail reader before we start posting rich text, or nobody will like >it. You should certainly build in the capability, in my opinion. > >If worst comes to worst, we could start comp.sys.next.rtf to handle the >specially formatted messages, but I don't think it would come to that. > >It would be great to have a way to include files in postings, too, so >people could drag them out of news into their directory structure. 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.) - 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. - 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. - 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.) - 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. 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. - -John H. Osborn -osborn@cs.utexas.edu
briand@rfengr.com (Brian Dear) (12/05/90)
All this talk of RTF in comp.sys.next is quite interesting. I thought I might mention that my company, Coconut Computing, is developing a NeXT version of COCONET(R), our graphics-based conferencing/BBS software that currently runs on 386/486 UNIX machines. We plan to support RTF and all kinds of other goodies on the NeXT version. -- brian dear coconut computing, inc. la jolla, california Registered NeXT Developers
windemut@lisboa.tmc.edu (Andreas Windemuth) (12/05/90)
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 Windemuthlclarke@questor.wimsey.bc.ca (Lawrence Clarke) (12/07/90)
The Vancouver (B.C. Canada) NeXT Users Group would be very interested in your multiuser BBS program COCONET(R) when available. Can you send any info on the product, beta copy, anything .... ? thanks briand@rfengr.com (Brian Dear) writes: > > > All this talk of RTF in comp.sys.next is quite interesting. I thought > I might mention that my company, Coconut Computing, is developing a NeXT > version of COCONET(R), our graphics-based conferencing/BBS software that > currently runs on 386/486 UNIX machines. We plan to support RTF and all > kinds of other goodies on the NeXT version. > > -- brian dear > coconut computing, inc. > la jolla, california > Registered NeXT Developers /==============================================================\ | lclarke@questor.wimsey.bc.ca | c/o TRIUMF Operations | | Compuserve: 70441,1776 | 4004 Wesbrook Mall | | Phone: +1 604 275-5902 | Vancouver, British Columbia | | FAX: +1 604 275-4184 | Canada V6T 2A3 | \==============================================================/
phred@oakhill.UUCP (Steve Menyhert) (12/07/90)
I have an idea with regard to the RTF newsreader. How about splitting
the newsgroup into straight text and an RTF newgroups. Normally, NeXT users
running the RTF newsreader will post to the RTF newgroup and have the newsreader
automatically strip out the RTF and cross post the message to the plaintext
group. This will create a lot more net traffic, but I never said it was a
perfect idea, it just solves the problem of excluding non-NeXT readers.
phred
--
Steve Menyhert | Motorola Incorporated
phred@oakhill.sps.mot.com | Microprocessor Products Group
"Honesty, Integrity, Generosity, Compassion" | Austin, Texas 78735-8598
- Suzanne Vega/Phillip Glass | m/d OE112 (512)891-4457
"For the lesson lies in learning, And by teaching I'll be taught.
There's nothing hidden anywhere, It's all there to be sought." - Procol Harum
"Women come and women go, Speaking of Michelangelo" - T.S. Eliotbriand@rfengr.com (Brian Dear) (12/07/90)
Wow, I've been getting lots of inquiries about the COCONET(R) BBS software for NeXT. Here's the scoop: we are porting COCONET(R) from SCO UNIX/XENIX/PC-machines to Macs and NeXTs. We've got a NeXT-related BBS set up here in San Diego (the San Diego NeXT Users Group BBS-- running on COCONET software on a 386 host machine for now; we'll move it over to NeXT when we're ready to start testing. By the way, you're all welcome to try out the San Diego NeXT Users Group BBS. The number is 619-456-2522, 1200/2400 bps, N-8-1. We'll be adding a 9600 bps line some time soon.) COCONET, in 25-or-so words: a UNIX-based BBS/conferencing program that supports e-mail, group forums, file exchange, online bitmap and vector graphics, CocoTunes (i.e., music in messages), hyperlinking in messages, and other goodies. With the NeXT version, we plan to support some things other platforms don't have, like LipService, etc. If you would like some info on COCONET, send me your mailing address. We will indeed be looking for a few beta testers of the NeXT version of our software when the beta becomes available.... Let me know if you'd like to be a beta tester. Please direct e-mail to: brian@coconut.com Brian Dear Coconut Computing, Inc. La Jolla, CA
jasmerb@prism.cs.orst.edu (Bryce Jasmer) (12/11/90)
In article <4305@oakhill.UUCP> phred@oakhill.UUCP (Steve Menyhert) writes: > I have an idea with regard to the RTF newsreader. How about splitting >the newsgroup into straight text and an RTF newgroups. Normally, NeXT users >running the RTF newsreader will post to the RTF newgroup and have the newsreade >automatically strip out the RTF and cross post the message to the plaintext >group. This will create a lot more net traffic, but I never said it was a >perfect idea, it just solves the problem of excluding non-NeXT readers. I think we should just have one newsgroup that contains all RTF. But to do this would take a lot of work so that all people would be able to read the articles. Aren't there other computers out there that know how to read RTF? How many computers actually have implemented it (besides IBM/Microsoft of course?) We should put together a suite of programs that would be able to read RTF news. One for ASCII terminals (simply strip out the control stuff and display in plain text), a version for X11, a version for PCs, a version for Macintosh, etc. etc. Build into rn the ability to strip out RTF control codes (like ^x does a rot-13.) When all of this is done (say 1995 or 1996 :-) then ALL of the newsgroups could be in RTF. Do I really think this can happen? No, but it certainly is fun to think about. I get tired of 80 column monospaced text. Bryce Jasmer jasmerb@ohsu.edu