On Sun, 24 Jan 2010 08:19:53 -0600 Anthony Liguori <anth...@codemonkey.ws> wrote:
> 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. The only real client writer we have thought it would be a good idea to disable them by default. If we don't this now and add a masking command later, then clients that don't want certain messages will have to deal with them between the window of qmp_swicth_mode and masking. I don't have strong opinions here though.
