GNU bug report logs - #38011
27.0.50; [PATCH] WIP on allowing Gnus backends to return header data directly

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#38011: closed (27.0.50; [PATCH] WIP on allowing Gnus backends
 to return header data directly)
Date: Mon, 18 Jan 2021 21:13:01 +0000

[Message part 1 (text/plain, inline)]

Your message dated Mon, 18 Jan 2021 13:12:37 -0800
with message-id <87h7ne0x16.fsf <at> ericabrahamsen.net>
and subject line Re: bug#38011: 27.0.50; [PATCH] WIP on allowing Gnus backends to return header data directly
has caused the debbugs.gnu.org bug report #38011,
regarding 27.0.50; [PATCH] WIP on allowing Gnus backends to return header data directly
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
38011: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=38011
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: bug-gnu-emacs <at> gnu.org
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: 27.0.50; [PATCH] WIP on allowing Gnus backends to return header
 data directly
Date: Thu, 31 Oct 2019 14:34:06 -0700

[Message part 3 (text/plain, inline)]

Right now, Gnus backends return article header data by writing it in a
parseable format into the `nntp-server-buffer', and returning one of the
symbols 'nov or 'headers, indicating how the data should be parsed.

This isn't great because it requires backends to first munge their data
into a format that looks like the NNTP format, which is then parsed
again, which is an extra layer of data transformation. It also makes use
of the `nntp-server-buffer', which is something I'd like to work on
reducing because it causes problems with threading and introduces
potential encoding bugs.

This patch provides the possibility for backends to return their own
headers (ie a list of vectors), though it doesn't actually change any of
the backends to do that -- that will be another patch.

I have one question at this stage: the 'nov or 'headers value gets
stored into the `gnus-headers-retrieved-by' variable. That variable is
later checked in a couple of places like so:

      (when (and gnus-fetch-old-headers
		 (eq gnus-headers-retrieved-by 'nov))
	(if (eq gnus-fetch-old-headers 'invisible)
	    (gnus-build-all-threads)
	  (gnus-build-old-threads)))

If the variable is 'headers, the `gnus-build-*-threads' functions don't
get called at all.

What's the difference between 'nov and 'headers, and why can we build
threads in one case and not the other? If backends were to return their
own headers, what value should they return? I'll also note that the nnir
version of this function returns 'nov regardless of what the "real"
backend function returned -- why is that?

I would love to use some other, more direct, heuristic to decide about
building threads or not, and get rid of the
'nov/'headers/gnus-headers-retrieved-by stuff altogether, but I don't
yet know how to do that.

Eric

[0001-WIP-on-allowing-Gnus-backends-to-return-headers-dire.patch (text/x-patch, attachment)]

[Message part 5 (message/rfc822, inline)]

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 38011-done <at> debbugs.gnu.org
Subject: Re: bug#38011: 27.0.50; [PATCH] WIP on allowing Gnus backends to
 return header data directly
Date: Mon, 18 Jan 2021 13:12:37 -0800

Robert Pluim <rpluim <at> gmail.com> writes:

>>>>>> On Sat, 16 Jan 2021 21:00:36 -0800, Eric Abrahamsen <eric <at> ericabrahamsen.net> said:
>
>     Eric> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>     >> On 01/05/21 09:47 AM, Lars Ingebrigtsen wrote:
>     >>> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>     >>> 
>     >>>> Morally the same: the agent has its own `gnus-agent-uncached-articles'
>     >>>> function, which consults the .agentview file, so it uses that instead of
>     >>>> `gnus-sorted-difference'. But the same idea.
>     >>> 
>     >>> Right.
>
>     Eric> [...]
>
>     >> Anyway, I'll keep looking at this patch for a bit, and see if I can find
>     >> any more problems with it.
>
>     Eric> I found a couple more, in agent file writing, and have pushed a commit
>     Eric> fixing that. So far as I can tell this now works as intended. I've run
>     Eric> side-by-side comparisons of master and this feature branch, messing with
>     Eric> the cache and the agent, and feel fairly confident that behavior is the
>     Eric> same in terms of header fetching, and files written to disk. I think I'd
>     Eric> feel okay merging this, but would also be happy to let it mellow longer.
>
> I think previous experience shows that the only way to find bugs in
> this kind of code is to foist it on us :-)

Bombs away, then!

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.