basic, but not really

basic, but not really

[Harry Putnam]

Setup:
emacs-24 from yesterday
gnus from 4 days ago.
Gentoo linux OS, at kenel 2.6.33

I like to keep a fairly large pile of downloaded news messages under
the agent.  I like to have them for experimenting with various
scripting or whatever.

I keep a dummy user acc., in addition to my own acc., on my home
machine for that purpose... All that acc. does is batch download
agentized groups from a cron job.  I just set the default category to
true and so whatever groups are there... get downloaded.

I stopped with my collection several mnths ago and deleted the huge
collection. In the meantime I did a full `from scratch' re-install of
the OS and have been slowly getting all the pieces back like I want
them.

I'd like to start building up my collection again. However, I don't
want to download everything on the server.  In this case the server is
gmane so that would be a really really big download.

But cutting to the chase here... 
Before; I managed the downloads with gnus-agent-batch and a cron job,
by giving the agents' default category a predicate of `true'.

That worked fine... but now, how can I start off by downloading only
the most recent 500 messages from each group, then go on with the new
ones each time the cron job rolls around.

I thought this might work:

Start by hand editing the .newsrc file prior to first start up of
gnus.  I added some 37 groups.   

So when gnus stared, it pulled down all available headers.  Of course
on `gmane' those number in the 10s of thousands.  But right now, its
just the header info.

I thought I might get the desired result by pressing `c'
(`gnus-summary-catchup-and-exit') to mark them all read, then on each
groups type 500 and press <enter>, causing the last 500 headers to be
displayed in summary buffer as `old'.  From there mark that 500 as
unread.

I did that to all groups thinking gnus wuuld ignore the messages marked
read and only download the 500 unread in the batch job... 

But as some of you probably already have guessed, it doesn't work that
way.

Gnus, still wants to download every message on the server.  And
neither Lars, nor I will be very happy with that.

OK, since marking articles as read doesn't stop the agent from
downloading them... ( when using the `true' predicate).  Then maybe I
need a more sophisticated predicate?

Or barring that, maybe some kind of scoring setup, that downgrades
read messages.

Anyway hopefully someone will be able to see the intent here and can
coach me a bit as to how to get things setup so that the agent
downloads only the last 500 on the server, and then continues each
day, downloading whatever has come in when the gnus-agent-batch job
roles around.

I still think there should be some way to do it using the predicate
`true'. but not sure how to stop gnus downloading `read' messages.

Or maybe to download by score, making read msgs lower than some
threshold the agent knows to use.

Those sections of the manual have a lot of info, but not many real
life examples.  Or maybe it would be more fair to say that I'm too
dense to apply the examples that Lars wrote in a funny/entertaining
way (probably to try keep from boring readers to death), to my
situation.  

Re: basic, but not really

[Ted Zlatanov]

On Sun, 14 Mar 2010 23:55:11 -0500 Harry Putnam <reader@newsguy.com> wrote: 

HP> Anyway hopefully someone will be able to see the intent here and can
HP> coach me a bit as to how to get things setup so that the agent
HP> downloads only the last 500 on the server, and then continues each
HP> day, downloading whatever has come in when the gnus-agent-batch job
HP> roles around.

HP> I still think there should be some way to do it using the predicate
HP> `true'. but not sure how to stop gnus downloading `read' messages.

You could use the gnus-registry to store a "downloaded" flag for every
message that's been downloaded.  The extra fields are for that kind of
ancillary information.

If you do use the gnus-registry like this, you do *not* have to set the
size to unlimited.  It won't remove entries with extra data when it
prunes old entries.

If you don't see a message in the gnus-registry, it hasn't been noticed
(messages are noticed when you enter a group, when splitting places
them, and when a copy/move/delete operation happens).  I don't know if
that would help you, the extra data approach seems more reliable.

Ted