Gnus development mailing list
 help / color / mirror / Atom feed
From: larsi@ifi.uio.no (Lars Magne Ingebrigtsen)
Subject: Re: performance respooling articles in nnmbox or nnbabyl
Date: 16 Mar 1996 10:58:04 +0100	[thread overview]
Message-ID: <x6wx4lse4n.fsf@eyesore.no> (raw)
In-Reply-To: gsstark@MIT.EDU's message of 15 Mar 1996 20:30:53 -0500

gsstark@MIT.EDU (Greg Stark) writes:

> The problem is that nnmbox and nnbabyl use a single file for all the
> groups and use the Gnus-* headers to indicate which group an article
> is in.  To refile an article, all that's necessary is to change the
> header, in theory.

Some header munging also has to be done to remove all those babyleze
headers.

> If it just went through and editted the headers for each article it
> would only have to move the gap over each article once in sequence,
> the equivalent of a single movement over the entire buffer.  In
> other words it should run in order N time.  If there's no clean way
> to get this behaviour without breaking the abstraction barriers (it
> looks like it shouldn't be too hard to me) then another order N
> algorithm would be to process all the deletions first then insert
> all of them at the end.

But you're only considering the particular case of respooling between
nnbabyl and nnmbox (and possibly nnfolder).  You're probably right
that Gnus does far too much work when moving messages between those
backends, but it's hard to see how to do what you suggest between,
say, nntp and nnml cleanly without adding a gazillion new functions.
(Each backend now only has to provide two functions to move, accept,
copy and respool articles -- `nn*-request-move-article' and
`nn*-request-accept-article'.)  The added complexity does not justify
the speed increases, which I'm not convinced would happen, actually.

(I don't know anything about those buffer gaps and stuff, though.  Why
do the gaps have to move?  Point stays at the end of the buffer being
respooled to, I think...)

Oh.  Uhm.  I misunderstood.  You meant respooling using the same
backend?  Those backends assume that the messages are stored using
ascending article numbers, so just changing the Gnus-* headers won't
work reliably.  In any case, that's not something most people would do
very often.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."


  reply	other threads:[~1996-03-16  9:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-03-16  1:30 Greg Stark
1996-03-16  9:58 ` Lars Magne Ingebrigtsen [this message]
1996-03-17 18:27   ` Greg Stark
1996-03-18 16:18     ` Lars Magne Ingebrigtsen
1996-03-17 18:39   ` Greg Stark
1996-03-18 16:18     ` Lars Magne Ingebrigtsen
1996-03-18 17:40       ` Greg Stark
1996-03-18 22:10         ` Lars Magne Ingebrigtsen

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=x6wx4lse4n.fsf@eyesore.no \
    --to=larsi@ifi.uio.no \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).