From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33858) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfUbx-0005bf-BC for qemu-devel@nongnu.org; Thu, 23 May 2013 08:27:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UfUbr-00066E-1N for qemu-devel@nongnu.org; Thu, 23 May 2013 08:27:13 -0400 Received: from mail-qe0-f41.google.com ([209.85.128.41]:50364) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfU3G-0008T9-Ru for qemu-devel@nongnu.org; Thu, 23 May 2013 07:51:22 -0400 Received: by mail-qe0-f41.google.com with SMTP id b4so1818159qen.0 for ; Thu, 23 May 2013 04:51:22 -0700 (PDT) MIME-Version: 1.0 Date: Thu, 23 May 2013 13:51:22 +0200 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Subject: [Qemu-devel] "Designing QMP APIs" at KVM Forum List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel Cc: Michael Roth , Luiz Capitulino 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 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. Stefan