From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:38437)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1UfUoh-0008Jw-Pq
	for qemu-devel@nongnu.org; Thu, 23 May 2013 08:40:30 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1UfUoY-0002LU-UL
	for qemu-devel@nongnu.org; Thu, 23 May 2013 08:40:23 -0400
Received: from mx1.redhat.com ([209.132.183.28]:2838)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1UfUoY-0002LK-MR
	for qemu-devel@nongnu.org; Thu, 23 May 2013 08:40:14 -0400
Date: Thu, 23 May 2013 08:40:09 -0400
From: Luiz Capitulino <lcapitulino@redhat.com>
Message-ID: <20130523084009.743e187f@redhat.com>
In-Reply-To: <87a9nlx5ic.fsf@codemonkey.ws>
References: <20130522134007.GA2051@t430s.nay.redhat.com>
	<20130522144448.GC23852@dhcp-200-207.str.redhat.com>
	<87fvxfkn49.fsf@codemonkey.ws>
	<20130523081837.GA3082@dhcp-200-207.str.redhat.com>
	<87a9nlx5ic.fsf@codemonkey.ws>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] RFC: Full introspection support for QMP
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: Anthony Liguori <aliguori@us.ibm.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Ronen Hod <rhod@redhat.com>, Amos Kong <akong@redhat.com>, Markus Armbruster <armbru@redhat.com>, qemu-devel <qemu-devel@nongnu.org>

On Thu, 23 May 2013 07:08:59 -0500
Anthony Liguori <aliguori@us.ibm.com> wrote:

> > then we don't need introspection at all. There's no user for it then.
> 
> Introspection is not the right approach to feature discovery.  The
> schema does answer the question of what features are enabled, it just
> answers the question of what the signature of the methods are.

(s/does answer/does not answer)

But there's an intersection here: a new enum value or new argument can
be a new feature too.

If we add new commands to query features, than I'm afraid that in the
long run feature discovery will be split in query-qmp-schema and the
specific feature discovery commands.

I'm not arguing in favor of one or another way, but we need to know
why and where we're going. The real motivation behind full introspection
is to allow commands to be extended.