From: Michal Sojka <sojkam1@fel.cvut.cz>
To: Jesse Rosenthal <jrosenthal@jhu.edu>, notmuch@notmuchmail.org
Subject: Re: Remote usage script updated
In-Reply-To: <m1k4h8syhi.fsf@watt.hwcampus.jhu.edu>
References: <87oc72xs35.fsf@lucky.home> <87aaibylqe.fsf@steelpick.2x.cz>
	<87tygiowyi.fsf@wsheee.2x.cz>
	<m1k4h8syhi.fsf@watt.hwcampus.jhu.edu>
User-Agent: Notmuch/0.5-103-g1253785 (http://notmuchmail.org) Emacs/23.2.1
	(x86_64-pc-linux-gnu)
Date: Fri, 11 Feb 2011 07:55:29 +0100
Message-ID: <877hd712n2.fsf@steelpick.2x.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: list

On Wed, 09 Feb 2011, Jesse Rosenthal wrote:
> By the way, I've also realized that most attachment downloading is done
> not by "--format=raw" but by "notmuch part". It's possible to do caching
> there as well. There are a few options there:
> 
>   * One option would be to just cache by the attachment number -- but
>     this is very fragile if you delete an attachment through mutt or
>     some other client that allows it.

This is obviously the simplest possibility. I do not know how often do
you (and others) delete attachments, but I do it rarely and usually I
delete all the attachments of the messages older than something. So this
would work for me.

Additionally, I have added the following command to the attachment
fetching code: 

    find ${CACHE} -ctime +$CACHE_MAX_DAYS -and -mtime +$CACHE_MAX_DAYS -print0 | xargs -r -0 rm -f

It deletes attachments older than one week (in my case) so it there is
some inconsistency, it would not last more than one week.        

>   * cache by the hash of the attachment. The idea is that asking the
>     server to fetch it, hash it, and send the hash would still save
>     time over sending the whole attachment. Probably -- though most
>     attachments are small enough and most connections are fast enough
>     that this might not actually matter.

If people do more weird things with their attachments, this is probably
the best solution.

>   * Actually stick the attachment hash in the json output in the first
>     place. But this would be a lot of trouble for a small gain for
>     very few.

Agreed.

-Michal