> > Separate on/off are 100% safe only when on/off itself has a reply, > hence the overhead. > > Currently 'noreply' will still send the error if the command has wrong > number of tokens, and thus no attempt is made to parse it (though I > could parse it, I think that wouldn't be right). To help this a bit > we may add a startup option to the server, 'close_on_error', and use > it for some errors that should never be ignored, so the error > condition won't go unnoticed.
'silent' would be more useful for bulk imports. Do two roundtrips around a bulk whatever, save from having to read. I don't think a close on error condition should be used in this case. As far as I'm concerned almost all errors should be transient... Especially if you have a library like dustin's which might not multiplex the connections. Think the binary protocol would handle this a lot better via the client opaque. -Dormando
