should gnus-registry.el be in the manual for Oort Gnus?

should gnus-registry.el be in the manual for Oort Gnus?

[Ted Zlatanov]

gnus-registry.el sort of snuck up on me.  I kept thinking it would
somehow be excluded from Oort Gnus' official release, but I realize
now that it's better to just add it to the manual because people are
using it and it's pretty stable.

I know this goes against the "no new features" status of Oort Gnus,
though.  So I need to know: should gnus-registry.el be officially
added to the manual, or should it be officially ignored until No Gnus?

As to what features the registry provides:

- tracking of message followups by message ID references

- tracking of followups by subject and sender (optional)

- tracking of spam processor invocations

- (planned) tracking of spam scores

Note that there is no special code in the registry to deal with
spam-related tracking, it's all generic "extra data" storage
associated with a message ID.  So the registry doesn't depend on
spam.el.

Thanks!
Ted

Re: should gnus-registry.el be in the manual for Oort Gnus?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I know this goes against the "no new features" status of Oort Gnus,
> though.  So I need to know: should gnus-registry.el be officially
> added to the manual, or should it be officially ignored until No Gnus?

It probably makes sense to wait until No Gnus.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: should gnus-registry.el be in the manual for Oort Gnus?

[Thomas Hühn]

Also sprach Ted Zlatanov <tzz@lifelogs.com>:

> - tracking of spam processor invocations

I know this isn't really spam.el-specific, but does that mean that one
could force spam.el not to register a mail with bogofilter twice?

I'm still playing around with my spam.el-configuration.
Actually I'd like to have something like this:

- new mail arrives
- fancy splitting (with spam-split at the beginning)
- spam goes into "nnml:spam", everything else into it's folder
- ham in the spam group is un-registered and moved into a suitable
  nnml-group
- spam in any "normal" group is registered and moved to spam where it
  expires

At the moment I am almost there. I have my spam-group and several
unclassified, "normal" groups. I don't classify them as ham because I
think mails in that group might be re-registered over and over again,
thus poisoning the bogofilter database. Am I correct there? I'd like to
be able to set any mark (excluding spam-mark) on mails in these groups.

Since I'm a bit lazy, I leave the spam group and they get registered
with bogofilter. But I do not move the "good" mails to a ham group to
train bogofilter with them. And now I'm ended up with 14 MB spamlist and
2.5 MB goodlist.

Am I right about that re-registering of good mails when I classify all
of my normal mail groups as ham or have I understood something wrong?

And that's where your registry comes into play? With that one could
avoid this and classify almost everything as ham groups?

BTW, the spam.el-specific part of my .gnus begins thus:

(spam-initialize)
(setq spam-install-hooks t)
;(spam-install-hooks-function)
(setq spam-use-bogofilter t)
(setq spam-mark-ham-unread-before-move-from-spam-group t)
(require 'spam)

I think that the Info indicated that one should put in
spam-install-hooks (which resulted in an error) before you
commited your big doc patch.

So can I leave out everything except spam-initialize and
spam-use-bogofilter?

Thomas

Re: should gnus-registry.el be in the manual for Oort Gnus?

[Ted Zlatanov]

On Fri, 02 Jan 2004, ding@daphne.gnuu.de wrote:

> Also sprach Ted Zlatanov <tzz@lifelogs.com>:
> 
>> - tracking of spam processor invocations
> 
> I know this isn't really spam.el-specific, but does that mean that
> one could force spam.el not to register a mail with bogofilter
> twice?

Yes, with registry tracking.  If you limit the number of registry
entries, however, you will eventually lose that tracking information.

I could add a flag to the registry "preferentially keep messages with
tracking information" if this is a problem.

> I'm still playing around with my spam.el-configuration.
> Actually I'd like to have something like this:
> 
- new mail arrives
- fancy splitting (with spam-split at the beginning)
- spam goes into "nnml:spam", everything else into it's folder
- ham in the spam group is un-registered and moved into a suitable
  nnml-group
- spam in any "normal" group is registered and moved to spam where it
  expires

I think your setup is almost exactly like mine, which is in the latest
Gnus manual.  Check mine out and let me know if something is unclear.

> Am I right about that re-registering of good mails when I classify
> all of my normal mail groups as ham or have I understood something
> wrong?

You're right, you would re-register without the gnus-registry
tracking.

> And that's where your registry comes into play? With that one could
> avoid this and classify almost everything as ham groups?

Yes.  I would advise, however, that you check registrations to make
sure things are working correctly.  They should, but it does not hurt
to be cautious.

> BTW, the spam.el-specific part of my .gnus begins thus:
> 
> (spam-initialize)
> (setq spam-install-hooks t)
> ;(spam-install-hooks-function)
> (setq spam-use-bogofilter t)
> (setq spam-mark-ham-unread-before-move-from-spam-group t)
> (require 'spam)
> 
> I think that the Info indicated that one should put in
> spam-install-hooks (which resulted in an error) before you
> commited your big doc patch.
> 
> So can I leave out everything except spam-initialize and
> spam-use-bogofilter?

This should be sufficient:

(setq spam-use-bogofilter t)
(setq spam-mark-ham-unread-before-move-from-spam-group t)
(spam-initialize)

Ted