From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/5899
Path: main.gmane.org!not-for-mail
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
Newsgroups: gmane.emacs.gnus.general
Subject: on Good Net-Keeping Seal
Date: Fri, 12 Apr 1996 00:12:09 +0200 (MET DST)
Message-ID: <199604112212.AAA00488@bombur2.uio.no>
NNTP-Posting-Host: coloc-standby.netfonds.no
X-Trace: main.gmane.org 1035146435 1732 80.91.224.250 (20 Oct 2002 20:40:35 GMT)
X-Complaints-To: usenet@main.gmane.org
NNTP-Posting-Date: Sun, 20 Oct 2002 20:40:35 +0000 (UTC)
Return-Path: ding-request@ifi.uio.no
Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.7.5/8.6.9) with SMTP id PAA25381 for <steve@miranova.com>; Thu, 11 Apr 1996 15:45:15 -0700
Original-Received: from mons.uio.no (6089@mons.uio.no [129.240.200.26]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) 
	id <AAA17705@ifi.uio.no> for <ding@ifi.uio.no> ; Fri, 12 Apr 1996 00:12:16 +0200
Original-Received: from ulrik.uio.no by mons.uio.no with local-SMTP (PP) 
          id <25951-0@mons.uio.no>; Fri, 12 Apr 1996 00:12:11 +0200
Original-Received: by bombur2.uio.no ; Fri, 12 Apr 1996 00:12:09 +0200 (MET DST)
Original-To: ding@ifi.uio.no
Xref: main.gmane.org gmane.emacs.gnus.general:5899
X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:5899

There was a recent discusson about Gnus vs. The Good Net-Keeping Seal of
Approval somewhere.  Here are a few resulting thoughts that occurred to me
afterwards:

- Strive for a distinction between between "novice" and "expert" config
  variables.  It should be difficult or impossible to diddle a "novice"
  config variable so that Gnus can post illegal articles.
  So you might have a variable with the list of headers that are always
  inserted and/or verified *in addition* to the standard ones, but
  if you want to remove/deform a standard header you must go via
  an "advanced" variable, a hook or an fset.

- Error messages should either contain enough help to let a novice
  correct the error, or it should tell him where to read about how to
  fix it.

  Error messages that refer to other text, could be put in a separate
  info file, and the message would pop up in a new Info buffer, with
  menu entries pointing to further reading.  Or perhaps some sort of
  pseudo-Info mode, with fewer keys that a novice can get lost with.

  To insert error messages from the NNTP server and such things into the
  Info node at run-time, the node must probably be written to a
  temporary file so that it can be visited later.  Otherwise you can't
  get back to the node after following the references it contains.
  (Well, it is possible to modify an Info node at run-time; you put
  `execute: (sexp)' after the node.  But I can't figure out how to make
  sure you get rid of the modification when you leave the node.


Regards,

Hallvard