From: David Bremner <david@tethera.net>
To: Michal Sojka <sojkam1@fel.cvut.cz>, notmuch@notmuchmail.org
Subject: Re: First draft of logging functionality.
In-Reply-To: <87ocaz3akd.fsf@steelpick.2x.cz>
References: <1286803617-17328-1-git-send-email-david@tethera.net>
	<87zkuj3hme.fsf@steelpick.2x.cz>
	<87hbgrhd1a.fsf@rocinante.cs.unb.ca>
	<87ocaz3akd.fsf@steelpick.2x.cz>
User-Agent: Notmuch/0.3.1-58-g6607fd6 (http://notmuchmail.org) Emacs/23.2.1
	(x86_64-pc-linux-gnu)
Date: Tue, 12 Oct 2010 10:16:30 -0300
Message-ID: <878w23eekx.fsf@convex-new.cs.unb.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: list

On Tue, 12 Oct 2010 13:38:42 +0200, Michal Sojka <sojkam1@fel.cvut.cz> wrote:
> 
> Why multiple log files? You may have the buffers for message logs in
> memory, right?

Well, maybe one log for tag operations, one for adding messages, etc... 
But it is easy enough to mark log entries by what they are.

> 
> Another thing to keep in mind is how it will behave with 'notmuch
> restore'. If do dump followed by resore you will have a very long log
> with no useful information in it. Some optimization may be employed here.
> 

Yes. This seems hard to optimize internally, but I was thinking of some
"log compression" function that comes up with a minimal equivalent set
of operations. I had in mind that this could be used to sync:
concatenate all the logs, and then compress to a minimal set of
operations.  This is still not completely thought out...
Another issue is that the buffer could get rather big during a restore,
but this is presumably fixable by flushing it if it gets too large.

All the best,

David