Re: Time for partial download of nnimap messages again?

[Simon Josefsson <jas@extundo.com>]

Steinar Bang <sb@dod.no> writes:

>>>>>> Simon Josefsson <jas@extundo.com>:
>
>> Steinar Bang <sb@dod.no> writes:
>>>>>>>> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann):
>
>>>> Maybe the conservatism comes from the thing being hard to
>>>> understand and not modularized as well as it could be...
>
>>> I really think it should be redesigned to become asynchronous.
>
>> IMHO using a framework like the URL package for backend
>> communication would be good.  Perhaps even extended further to be
>> more thread friendly.
>
> With asynchronous backends, the idea is that you don't need threads.
> The network traffic is powered by the event loop checking for waiting
> input on sockets.

I don't think an asychnronous backend interface is enough -- at least
nnimap spend an non-neglible amount of its time processing, not
waiting for IO.  So it would still lock up Emacs when doing things.
And Gnus, where most of the time is spent when entering groups,
pressing g, etc, is not waiting for IO most of its time either.  (Try
elp-instrument-package on gnus-, imap-, and nnimap-. Only when doing
very big operations will imap- consume much of the time, and the IO
waiting is there.)

> But the backend interface would need a complete restructuring: from
> "request/response and then use the response to draw summary and
> article buffers" to "send a callback with the request, and have the
> callback draw summary and article buffers, as data arrives".

Yup.  Having incrementally built summary buffers (when you scroll the
emacs buffer, with some intelligent prefetching) would be quite nice.