Re: Gnus' speed

[Daniel Pittman <daniel@rimspace.net>]

Ted Zlatanov <tzz@lifelogs.com> writes:
> On Wed, 29 Jul 2009 10:03:05 +0200 Daniel Clemente <dcl441-bugs@yahoo.com> wrote: 
>
> DC> El dt, jul 28 2009 a les 23:03, Leo va escriure:
>>> and Gnus has been pretty fast except when
>>> downloading attachments.
>
> DC>   I experience this too. When I press ENTER, Gnus downloads all
> DC>   attachments by default, even if they are >10 Mb and I don't want
> DC>   them.  Probably there's a variable which says „only download
> DC>   attachments when I ask you to“, but I don't know which
> DC>   one. gnus-.*attachment didn't match any.
>
> IMAP, at least, supports downloading any part of a MIME message
> individually.  I don't believe Gnus uses that functionality but it
> could.

It does, indeed.

> I think the backend rewrite would be fairly minor, but there are many
> internal and user-visible functions in Gnus that also will need to be
> modified.  It's a lot of work.

I think that saying "fairly minor" is misleading here: adding the capability
to the IMAP backend isn't enormously hard, but defining a sound (and portable)
API, and implementing it, is quite non-trivial.

As a guide, if someone does want to do this, from when I investigated this
some time back I found the best strategy was likely to be:

1. Define an API for "obtain the MIME structure" in the back-ends.
2. Implement it in the "front-end" based on fetching the whole article.
   You need this later anyhow.
3. Replace all the bits of code scattered all over the place that take the
   whole article and look for structure with use of the API above.
   Just keep fetching the whole article and all at this point, when it comes
   to getting the data out.

4. Replace the front-end MIME structure code with a back-end API, and use the
   same code for the default implementation for back-ends that don't provide
   an optimized version.
5. Maybe, add an IMAP version at this point.

6. Define an API for fetching a MIME part based on the structure.
7. Provide a default implementation, then move down code that parses the
   article into parts into the content.

8. Replace all the code that assumes it sits in a full article buffer with
   something like '(gnes-in-article-buffer &body)' that will build a suitable
   buffer, then run the old code.
9. Gradually replace instances of that with content-aware versions of the
   same.

That way you can release something useful along the way, building useful code
at each stage, without having to get everything done at once.  You can look
forward to person-months if not person-years of work in the transition,
though.

Regards,
        Daniel
-- 
✣ Daniel Pittman            ✉ daniel@rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons