all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 38011@debbugs.gnu.org
Subject: bug#38011: 27.0.50; [PATCH] WIP on allowing Gnus backends to return header data directly
Date: Fri, 01 Nov 2019 11:41:26 -0700	[thread overview]
Message-ID: <8736f7l9rd.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <87a79f3cu3.fsf@gnus.org> (Lars Ingebrigtsen's message of "Fri, 01 Nov 2019 15:12:20 +0100")

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> 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.
>
> Great!
>
>> 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?
>
> It's not about threading per se, but about displaying information about
> already-read articles (or more precisely -- about articles not in the
> set that was requested).  Threads are build no matter how the backend
> delivers the data.
>
> If nn-*retrieve-headers supports NOV fetching, then certain Gnus
> variables about filling in threads with "old" articles is switched on,
> because fetching extra NOV headers is fast (you just say "fetch 100-150"
> instead of "fetch 100-110,120-130,150").  With the backends that fetch
> head by head, this is slow, so it's not done.
>
> It's basically a distinction between NNTP and almost all the other
> backends.

Okay, that makes sense. So it's basically a flag saying header retrieval
is cheap enough that we might as well pull in more old messages than we
otherwise would. For example, nnmaildir builds and stores nov data
(which drives people with large maildirs insane because it takes
enormous amounts of time and space), so it returns 'nov, but if we ever
got rid of that (or made it optional) it would return 'headers.

I'm going to assume that any backend capable of returning its own
headers is probably going to... return 'headers. At any rate, as I
implement this for various backends, I'll start with the ones that
return 'headers to begin with. At some point, though, I'd still like to
get rid of this flag and build the distinction into the backend
functions themselves.

Hmmm... nnmaildir needs some love.

Eric





  reply	other threads:[~2019-11-01 18:41 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-31 21:34 bug#38011: 27.0.50; [PATCH] WIP on allowing Gnus backends to return header data directly Eric Abrahamsen
2019-11-01 14:12 ` Lars Ingebrigtsen
2019-11-01 18:41   ` Eric Abrahamsen [this message]
2019-11-01 20:52     ` Eric Abrahamsen
2019-11-02 14:49     ` Lars Ingebrigtsen
2019-11-07 23:21       ` Eric Abrahamsen
2019-11-08 21:03         ` Lars Ingebrigtsen
2019-11-08 21:43           ` Eric Abrahamsen
2019-11-08 21:58             ` Lars Ingebrigtsen
2020-03-29 19:50               ` Eric Abrahamsen
2020-04-30  4:50                 ` Lars Ingebrigtsen
2020-09-27  4:13                   ` Eric Abrahamsen
2020-09-27 12:16                     ` Lars Ingebrigtsen
2020-09-27 23:41                       ` Eric Abrahamsen
2021-01-02  3:18                         ` Eric Abrahamsen
2021-01-02  5:59                           ` Lars Ingebrigtsen
2021-01-02 20:49                             ` Eric Abrahamsen
2021-01-03  7:45                               ` Lars Ingebrigtsen
2021-01-03 19:53                                 ` Eric Abrahamsen
2021-01-04  9:05                                   ` Lars Ingebrigtsen
2021-01-04 18:09                                     ` Eric Abrahamsen
2021-01-05  8:47                                       ` Lars Ingebrigtsen
2021-01-05 17:02                                         ` Eric Abrahamsen
2021-01-17  5:00                                           ` Eric Abrahamsen
2021-01-18 10:48                                             ` Robert Pluim
2021-01-18 21:12                                               ` Eric Abrahamsen
2021-01-18 16:37                                             ` Lars Ingebrigtsen
2021-01-03 19:54                                 ` Eric Abrahamsen
2021-01-03 21:38                                   ` Eric Abrahamsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8736f7l9rd.fsf@ericabrahamsen.net \
    --to=eric@ericabrahamsen.net \
    --cc=38011@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.