On Fri, 15 Jan 2010 14:49:14 +0100, Jed Brown <jed@59A2.org> wrote: > It wouldn't bother me at all if I lost my last few seconds of > interactive tagging due to something catastrophic like losing power. I > think there is still (post #250) a case for supporting some asynchronous > operations. I was wondering what the protocol would be like for non-blocking commands to a notmuch daemon. I have no experience with these things, but I was thinking something along the lines of (not worrying about wire encoding) open_session - basically just generates a unique id to allow grabbing results of commands to be collected. queue command session arguments I guess the command dispatcher could just be a thin replacement for command-line argument parsing. gather session return all output from session flush session close session Is this over/under engineered? I spent roughly as long on the design as it took me to type :). Maybe the whole session id thing is redundant and could be done at the socket level. Or, getting more serious about the whole thing, maybe each queue operation should return an identifier. OK, discuss amongst yourselves ;) d