Re: Message buffers associated with files?

[Usenet news <news@sunsite.auc.dk>]

.com> <x63f0cwd3n.fsf@eyesore.no> <ufau3ssffup.fsf@sina.hpc.uh.edu> <x67mpjddor.fsf@eyesore.no>
From: Paul Franklin <paul@cs.washington.edu>
Date: 26 Sep 1996 22:23:22 -0700
Message-ID: <r9qenjobkfp.fsf@fester.cs.washington.edu>
Organization: Computer Science, U of Washington, Seattle, WA, USA
Lines: 66
X-Newsreader: Red Gnus v0.34/Emacs 19.34
Path: fester.cs.washington.edu
NNTP-Posting-Host: fester.cs.washington.edu

>>>>> Lars Magne Ingebrigtsen writes:

 > Well -- manual pages aren't particularly message-like.  New manual
 > pages seldom appear, and it isn't really interesting to mark read
 > manual pages in any way, so I don't think an nnman backend would make
 > much sense.

This is the problem I ran into when I was contemplating writing
nngnats, and all of the time I had slated to actually write it went
into discovering how these models don't match.  :)  (And now I've
left my summer job and don't use nngnats anymore.  But now I'm really
wanting imap stuff again.  Sigh.)

The issues with nngnats are even more difficult--files change, and you
want to notice when they do.  Not only can the content change, but the
status can change as well--essentially, the back end wants to keep
track of some of the flags.  And some files you want to see again
whenever they change, while others you don't want to see again.  This
could be done through scoring, but the ideal thing would be to
redefine dormancy as articles which magically become either unread or
ticked when they change.  (This works well with gnats, since you
should never have followups; you just keep adding to the same
document.)

So here's my wish list for backend capabilities needed by nngnats
(which should be a superset of those needed for a nice nnman):

* Backends can affect the marks of articles.  Hmm.  Looks like this is
  now possible by coding nngnats-request-update-info.  This would be
  the time to awake dormant articles when they've changed.

* Backends can contribute additional fields.  Users can limit by these
  fields, possibly through a special '/' command which prompts you for
  a backend-specific field name.  Users can also score on these
  fields.  (For nngnats, this would include responsible person,
  severity, priority, ...)

* Backends can have persistent, internal state.  For nngnats, this
  would be the last mod date of the gnats report, and possibly 1-2
  other things so the files don't have to be scanned every time.  (Or
  maybe this should go into files in a directory specified by a server
  parameter.  It can't go into a gnats or man dir, since they're
  shared dirs.)  For nnman, this would be the article numbers of man
  pages.  (Hmm.  Pretty soon, we'll have a .gnus directory for all of
  this stuff.)

* Backends should be able to reject incorrectly-formatted messages in
  -request-replace-article and -request-accept-article, probably via a
  return value.  This would allow someone to submit or edit problem
  reports from gnus with appropriate checks in place.

* Backends should be able to lock files for editing, if that's
  necessary.  (I'm not sure if nngnats actually needs it, but it seems
  really useful.)

Hmm.  We're closer than I thought.  One has been addressed, and one
has an alternative I hadn't thought of earlier which probably is
better anyways.

(For the record, someone else wanted nngnats groups to be basically
query parameters for querypr.  My personal opinion is that gnus'
scoring and limiting mechanisms can deal with this quite adequately.
And I wanted to read the gnats list of bug reports directly, so I
could base the active file on it.)

--Paul