[notmuch] asynch operations protocol
David Bremner
bremner at unb.ca
Fri Jan 15 05:59:54 PST 2010
On Fri, 15 Jan 2010 14:49:14 +0100, Jed Brown <jed at 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
More information about the notmuch
mailing list