Re: storage.conf: Using "flag" as a storage key
Russ Allbery
> I want to play with the 'dontrejectfiltered' option in inn.conf on a
> transit server.
> One thing I miss after a first check of the manpages: I'd like to store
> these "flagged" articles (i.e. rejected by cleanfeed but _not_ dropped,
> is there a better word for this?) in a separate buffer. This buffer may
> be rather small, e.g. rotate in 24 hours. That's enough time to retrieve
> the article in case I'd like to know why cleanfeed didn't like it but it
> wouldn't consume to much disk space/history/etc. Otherwise "Binary in
> non-binary group" articles would have an impact on the retenition time
> of regular articles.
> Is it possible to use this flag as a storage criteria? A very short
> glance into the sources suggests this should be not too difficult.
It's not currently possible to do this. It's certainly something that
would be desirable to add, although I'm not sure the best general way to
do it. I'd really eventually like to have a more generalized tagging
engine that would allow the filtering logic to apply any of a variety of
tags to articles, and then use that tag information in both newsfeeds and
the storage subsystem, but that's a larger project.
I probably won't get a chance to work on anything like this until after
the storage API is redesigned. If you come up with something in the
meantime, I'd be inclined to accept it since it's likely that the config
files and the like will need to go through an upgrade process anyway and
we can fiddle with the way it's specified then.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
Christoph Biedl
> It's not currently possible to do this. It's certainly something that
> would be desirable to add, although I'm not sure the best general way to
> do it. I'd really eventually like to have a more generalized tagging
> engine that would allow the filtering logic to apply any of a variety of
> tags to articles, and then use that tag information in both newsfeeds and
> the storage subsystem, but that's a larger project.
Funny enough, I'm thinking of quite the same things: Having the ability
to attach several flags to each article. These flags would include
"cleanfeed didn't like it" and "A cancel message for that article has
been received"; they could be used for storage, newsfeeds and even
reading: The news admin can read everything and decide to locally
un-cancel an article, or grant "uncensored" access to those users who
really want to read all the junk.
The obvious place to store such information was another column in the
history file - thus making up/downgrade very difficult and breaking
zillions of scripts out there. Including mine. Well, in INN 3.0 then ...
I'd also modify the perl/python filter (besides renaming it to
"embedding") in order to not simply return a boolean flag but a bunch of
states like "drop it", "drop it but do not block in history",
"accept", "accept but use 'foo' as a storage key", "retry later" etc.pp.
> I probably won't get a chance to work on anything like this until after
> the storage API is redesigned. If you come up with something in the
> meantime, I'd be inclined to accept it since it's likely that the config
> files and the like will need to go through an upgrade process anyway and
> we can fiddle with the way it's specified then.
Well, I'm glad to tell that I'll have access to a fast computer that will
serve as a transit feeder in the future but with a longish test period
before that. It will receive a not-really-non-binary full-feed at no
extra cost. Writing a patch for my question is on the list of things to
do during that time.
Christoph