Re: What is happening in agentized groups?

[Harry Putnam <reader@newsguy.com>]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:

> Harry Putnam <reader@newsguy.com> writes:
>
> [...]
>
>> But back to this business of the undownloaded entries in summary
>> buffer:  I'm not sure I see what the value of that is.  In my case it
>> just gives me a huge summary buffer to process if I should happen to
>> enter the group with C-u.
>
> Actually, the word "Undownload" in the summary buffer has different
> meaning from the one marked as @. Gnus agent grabs articles in three
> steps, 1) updating the active file (automatically when you type 'g' in
> the group buffer), 2) braiding .overview files (when you type `J s' or
> automatically when you enter the group plugged and if gnus-agent-cache
> is non-nil), 3) grabbing the articles (when you type 'J s' and if the
> predicates return true).

This is getting confusing...  
   These are marked Undownloaded and have the `@' on them.
   For example, my current gnu.emacs.gnus, if openned with C-u
   while unplugged begins with:

1@  31-Dec [   0: Gnus Agent          ] [Undownloaded article 48094]

   [...] snipped 1200+ just like it with consequtive numbers up to:

1@  31-Dec [   0: Gnus Agent          ] [Undownloaded article 49318]

   Then I have the messages beginning:
20O  30-Jan [  25: A. L. Meyers  ] back to the ... 49319
   up to:
 1R  25-Feb         [  40: Shankar Rao ... 50077

None of the first group are on the server.  The lowest number on
the server is 48323

I don't really follow the formula you listed, and haven't for probably
2 yrs or more.  I do the fetching in batch mode with cron.  Which kind
of follows the formula I guess.  It has worked fine until recently.
Possibly since the patch you mention, not sure.

> If you enter a group unplugged without step 2, some articles are shown
> as "Undownloaded article ???" in the summary buffer, because the NOV

What situation would allow a user to enter without step 2?

Apparently I am missing step 2 in gnus view of things.  But this was
not happening until those `Undownloaded' entries started showing up.

Maybe this new mechanism doesn't work well with my system of batch
downloading, and running unplugged all the time.  Allowing a function
snarfed from Lars long ago to to handle passing the info from the
batch downloads to .newsrc.eld


In the unplugged gnus, I call this:

 (defun pgnus-unplugged ()
   (interactive)
   (setq gnus-plugged nil)
   (gnus))
(setq gnus-read-active-file t)

To update my groups and mail with the latest stuff gathered in the
batch fetchs run by cron.

The batch emacs that does that part, loads this function first:

 (defun lars-fetch-news ()
   (interactive)
   ;(push "/usr/local/pgnus-0.96/lisp" load-path)
   (let ((init-file-user "")
 	(gnus-always-read-dribble-file t))
     (gnus))
   (gnus-group-send-queue)
   (gnus-agent-fetch-session)
   (gnus-group-quit))

Sending and fetching

In the case above, and in my other groups.  If I were to change the 
@ to % none of them will be downloaded because they do not exist on
the server.  Yet thousands of them clutter up my summary buffer, if
entered with C-u.

[...]

> Now, the question is what about canceled or expired articles. Ideally,
> canceled articles should not be listed, and expired articles on the
> server should not either, but agent-expired articles, which are still
> on the server, should. However, nnagent knows neither whether they
> exist on the server, nor whether they are canceled or expired on the
> server (at least not in the current mechanism).  So, for the safety
> reason, let's assume those articles exist.

Isn't there a way for gnus to know if they are not on the server?
In the situation I described above, those messages will NEVER be
braided into .overview, yet I have thousands of lines of summary
buffer devoted to telling me about messages that nothing can be done
about. 

I remember a problem we had going way back before pgnus-0.91 I think.
Kind of the reverse situation, where messages in agentized groups
would disappear from gnus view when they were expunged off the server,
but really still be in the local directory.

Lars fixed that in version 91 I believe (or close) and since then gnus
knows about the agent articles even if not on the server.  Maybe
something in that mechanism will help?

Or even if it is necessary to poll the server, and find out which are
not available, seems it would be better than just continuing to show
the Undownloaded summary lines until hell freezes over.