From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:40459)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1UfUvO-00044a-Rk
	for qemu-devel@nongnu.org; Thu, 23 May 2013 08:47:23 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1UfUvH-0004IV-Q5
	for qemu-devel@nongnu.org; Thu, 23 May 2013 08:47:18 -0400
Received: from mx1.redhat.com ([209.132.183.28]:37185)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1UfUvH-0004IE-Ho
	for qemu-devel@nongnu.org; Thu, 23 May 2013 08:47:11 -0400
Date: Thu, 23 May 2013 08:46:55 -0400
From: Luiz Capitulino <lcapitulino@redhat.com>
Message-ID: <20130523084655.41fb8f63@redhat.com>
In-Reply-To: <CAJSP0QW_LqQAKkTxqRSyyBOAXyAmy3Bg0FBt-jVyUSe2B+p5sQ@mail.gmail.com>
References: <CAJSP0QW_LqQAKkTxqRSyyBOAXyAmy3Bg0FBt-jVyUSe2B+p5sQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] "Designing QMP APIs" at KVM Forum
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, Michael Roth <mdroth@linux.vnet.ibm.com>

On Thu, 23 May 2013 13:51:22 +0200
Stefan Hajnoczi <stefanha@gmail.com> wrote:

> With better QMP introspection on the horizon and work in various
> subsystems pushing QMP boundaries it would be useful to bring together
> the latest best practices for designing QMP APIs.
> 
> There are design rules for keeping QMP APIs extensible and for
> allowing clients to detect the presence of features.  There is also
> QEMU-side infrastructure like event rate-limiting, which developers
> should make use of where appropriate.
> 
> Is anyone willing to bring together the best practices and present
> them at KVM Forum this year?

I think this is a great idea and I vote for Eric to prepare a presentation.
Eric is doing an exceptional work on QMP command review, he is also
experienced on the client side.

> I think that could help set the standard for QMP APIs.  A set of
> slides or wiki page can be a reference to developers that stops us
> working from first pricinples every time a new API is added.

I was working on a doc to be added to docs/. It wouldn't be anything
fancy, but I ended up not finishing it.