[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