Re: nnimap-split-download-body removed?

[Eric Abrahamsen]

Bodertz <bodertz@gmail.com> writes:

> I can confirm that setting `nnimap-split-download-body-default' to t
> works as intended.  I really should have tried that first.

No worries, that's good news.

> It sounds like the removal wasn't intentional, so hopefully it can be
> added back.

I think we could just resurrect the old `nnimap-split-download-body'
defcustom, then fix the docs. I don't see any need for this
`nnimap-split-download-body-default'.

> It seems to download the body before the splitting, which is
> unfortunate.  It would be better if it only downloaded the body when the
> split required it.  Or if it could match the sender against a whitelist
> of accepted senders and only download when they matched.  Or the same
> thing but with the summary, but then it's getting close to just adding
> a simpler split system before the real one, which is a little odd.
>
> So I don't forget, someone also suggested `nnimap-split-download-body
> size', which might be a useful addition:

The code Ted's referring to is long gone, and things are a lot simpler
now. We could re-introduce some of the complexity, but I wasn't there
for the earlier versions and don't know the arguments for why the code
is the way it is now. The problem with checking the headers or the
message size before downloading the body is that you're then issuing one
FETCH to get all the messages without their bodies, and then issuing
another to get the bodies you want, likely just the same list as before.

That seems like it would end up being pretty inefficient, and I wouldn't
be surprised if it turned out that we had to issue one FETCH per message
we wanted the body for. I'll admit I haven't looked at this part of the
code closely, but...

Eric