earle@jplopto.uucp (Greg Earle) (02/04/88)
Although my initial playing around with `gnus' leaves a good impression, after trying a followup posting, a couple of things I noticed disturbed me: (1) GNUS sets the `Path:' header to be `NNTP-host!user' where NNTP-host is the name of the NNTP server that GNUS uses. This is patently wrong, although one can say that the alternative, using the current system name, is not much better. At least in this case there is a reasonable chance that given a generated Path: like ...!NNTP-server!NNTP-client!poster that if someone replies using a reversed Path:, hopefully NNTP-server will see `rmail NNTP-Client!poster' and be able to grok that successfully. Certainly the existing code will fail. (2) GNUS seems obligated to insert a Message-ID: field. I don't know how `rrn' does it, but I do know that using `rrn' results in the NNTP server having its own inews create the message ID, like `<1234@nntp_svr.some.do.main>' which makes life easier for other Usenet software to deal with. Instead, GNUS creates a Message-ID: field that concatenates the user's login name, converted to all CAPS, then a `.GNUS' followed by a number (1 or more?) thus a followup by me would get tagged with something like Message-ID: <EARLE.GNUS1@jplopto.JPL.NASA.GOV> For some reason, the remote inews on the NNTP server plays hands-off with this Message-ID field, so reading the subsequent article shows this horrid kludge in the final posted copy. I've only seen formats like this from sites using BABYL message formats (Simtel-20, MIT, etc.) for news articles (which were probably gatewayed from mailing lists, and were thus mail msgs.). Now I suppose there's nothing *illegal* about this, but if there's some way to let the remote inews on the NNTP server create the Message-ID (like not putting one in before shipping it to the remote inews), then that should be done instead. (3) When entering a newsgroup, GNUS decides you must want to see the beginning of the first unread article in the group, so it sticks it in the buffer. For remaining articles, you can mark them as read (i.e., skip them) via `d' or `k' or whatnot, but you get the first one no matter whether you want it or not. I sentence the author to using GNUS at 1200 (or 300!) baud to see how annoying this can be. The default should be cursor on 1st article subject line, with read buffer *empty*. If you want to see #1, you'll hit SPACE like for any other one. (4) GNUS keeps a window of 4 lines of Subject: lines for reference, while reading. This is a good feature, but I don't understand why when the last article in the window is read, the window only scrolls up two lines, showing the (now current) next article and one after that, instead of scrolling N-1 (i.e., 3; I don't know if this little window is dependant on the rest of the window size available for its own size) lines so that the article you just read is the only one left, and 3 new Subject: lines appear. 2 lines of previous context is acceptable for the read buffers (although personally I prefer just 1, but Emacs convention being what it is), but is unwieldy for just a four line window. Note that #3 & #4 are somewhat nit-picky; I can appreciate the amount of time put into the package, and I applaud the author's diligent efforts (I can even overlook the spelling errors, after all his English is a wee bit better than my Japanese! (-: ). They are somewhat curious, though. Three cheers for a job well done, anyway. Greg Earle earle@jplopto.JPL.NASA.GOV Indep. Sun consultant earle%jplopto@jpl-elroy.ARPA [aka:] Rockwell Science Center earle%jplopto@elroy.JPL.NASA.GOV Thousand Oaks, CA ...!cit-vax!elroy!smeagol!jplopto!earle
umerin@photon.stars.flab.Fujitsu.JUNET (Masanobu UMEDA) (02/26/88)
Posting-Front-End: GNU Emacs 18.47.5 of Mon Nov 2 1987 on photon (berkeley-unix) In article <5372@elroy.Jpl.Nasa.Gov> earle@jplopto.uucp (Greg Earle) writes: > (1) GNUS sets the `Path:' header to be `NNTP-host!user' where NNTP-host > is the name of the NNTP server that GNUS uses. This is patently wrong, `Path:' field is intended to be used for feeding news articles effectively, not by mail. If host name of NNTP client is included in the path, the host will not receive the article even when the host is receiving or relaying usenet news. This is absolutely wrong. > (2) GNUS seems obligated to insert a Message-ID: field. I don't know how > `rrn' does it, but I do know that using `rrn' results in the NNTP server > having its own inews create the message ID, like `<1234@nntp_svr.some.do.main>' > which makes life easier for other Usenet software to deal with. Instead, > GNUS creates a Message-ID: field that concatenates the user's login name, > converted to all CAPS, then a `.GNUS' followed by a number (1 or more?) thus > a followup by me would get tagged with something like > Message-ID: <EARLE.GNUS1@jplopto.JPL.NASA.GOV> `rrn' (standard NNTP client program) has its own client inews program which should be installed publicly in local host by system administrator (or root). A number in Message ID can be easily shared by inews between users in the local host. On the other hand, GNUS need not to be installed publicly because it does not depend on any other standard news programs except for NNTP server. So, there is no safe way to share a number of message ID between other GNUS users in the local host. I think NNTP server should do the job. Anyway, what kind of Message ID do you expect? > (3) When entering a newsgroup, GNUS decides you must want to see the beginning > of the first unread article in the group, so it sticks it in the buffer. Just type `=' instead of SPACE. You may not be able to find out the command because of my Japanenglish. (:-) > (4) GNUS keeps a window of 4 lines of Subject: lines for reference, while > reading. This is a good feature, but I don't understand why when the last > article in the window is read, the window only scrolls up two lines, showing > the (now current) next article and one after that, instead of scrolling > N-1 lines so that the article > you just read is the only one left, and 3 new Subject: lines appear. 2 > lines of previous context is acceptable for the read buffers , but is > unwieldy for just a four line window. This is Emacs feature. GNUS does nothing about scrolling. -- Masanobu UMEDA umerin@flab.flab.Fujitsu.JUNET umerin%flab.flab.Fujitsu.JUNET@uunet.uu.NET