On 01/24/2010 08:17 AM, Avi Kivity wrote:
On 01/24/2010 04:04 PM, Anthony Liguori wrote:
I agree with that, but we can look at async messages as a baseline
protocol capability (thus no negotiation required), and the new
command only enabled individual messages.
To be honest, I don't think there's really a need to mask individual
messages. A client can always ignore messages it doesn't care
about. There is no side effect of receiving a message so there is no
functional implication of receiving messages you don't care about.
The only time it would matter is if we had a really high volume of
messages. I'd suggest waiting until a message is introduced that
could potentially have a high rate and then implement a mechanism to
mask it. For now, it just adds unnecessary complexity.
Fair enough. But then, why can't all clients do that? Dropping an
async notification is maybe one line of code.
I agree. The only argument I can imagine for masking is if we had a
really, really high volume event that caused bandwidth issues. I don't
think that's an appropriate use of async messages though so I don't
think this will ever happen.
Regards,
Anthony Liguori
