Re: Time for partial download of nnimap messages again?

[Simon Josefsson <jas@extundo.com>]

Steinar Bang <sb@dod.no> writes:

> Now that agent is always used by nnimap as a local cache

I'm not convinced the change is good, there are at least some known
problems we need to solve:

1) The daemon stopped working for someone, probably related by this
   change.

2) Expiring the agent directory doesn't happen automatically.  This
   might be what some people want, but not others.

3) Unagentized nnimap (and other) servers do not get local caching at
   all.  Which means people that don't agentize their nnimap server
   actually get no overview cache at all, since the nnimap cache has
   been disabled. Bad bad!  I think non-local servers should be
   agentized by default, but I'm not sure how to change it in a
   backwards compatible way.

4) Slowness in expiring?  Fixed?

5) Any mark problems still occuring?

If those who disabled the agent re-enabled it and reported the
problems they see, it would be very useful.  If there are more
undiscovered problems that looks difficult to solve, reverting the
default value change should be considered.

> it may be time to once more start looking at partial downloads of
> MIME messages?

Feel free to do so. :-)

> Eg. downloading the text part, but leave that big videoclip on the
> server, until we decide to look at it.
>
> A quick revisit of the idea:
>  - in the agent cache, replace the delayed parts with a
>    message/external-body URL part
> 	<http://www.faqs.org/rfcs/rfc2017.html>
>    where the URL is an IMAP URL:
> 	<http://www.faqs.org/rfcs/rfc2192.html>
>  - when the user wishes to view or save the delayed part, it is
>    downloaded from the server, and the message/external-body is
>    replaced with the actual part
>
> What Simon didn't like about this, IIRC, was that you changed the
> message from the original.
>
> But you don't, really.  The original message is kept in its priestine
> state on the server.  What happens to the cached message is just an
> internal Gnus implementation issue, IMO.

Yup.  I have troubles visualising how the UI for this would work
though.  It should handle disconnected support too.  But I guess it
isn't impossible to do.  Let's see.

1) Have a nnimap-undownload-part variable that can contain predicates
   such as (and (string= content-type "audio/mp3") (> size 123456))
   that says which parts to not download.

2) In nnimap-request-article (possibly with help from
   nnimap-request-headers for simple predicates) evaluate the
   predicate and download all other MIME parts, and replace the
   offending part with the multipart/external IMAP URL stuff.

3) In gnus, somehow add a mark saying that an article is not fully
   downloaded.  Maybe a agent specific mark?

4) In gnus, mark the MIME button for replaced entities somehow, to
   make it clear that Gnus replaced it.

5) In gnus, have a command to re-download the whole message.  It
   should work even when disconnected (compare the @ download mark).

6) In gnus, somehow fix C-d to reflect the external property as well?

As I personally don't really need the feature, I don't think I'll do
much more than this though. :-)