From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=52262 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OFBkW-0000HF-1E
	for qemu-devel@nongnu.org; Thu, 20 May 2010 15:49:45 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1OFBkU-000128-71
	for qemu-devel@nongnu.org; Thu, 20 May 2010 15:49:43 -0400
Received: from mx1.redhat.com ([209.132.183.28]:64630)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1OFBkT-00011o-MO
	for qemu-devel@nongnu.org; Thu, 20 May 2010 15:49:42 -0400
Message-ID: <4BF5924E.5050805@redhat.com>
Date: Thu, 20 May 2010 22:49:34 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 0/6]: QMP: Fix issues in parser/lexer
References: <1274303733-3700-1-git-send-email-lcapitulino@redhat.com>
	<4BF45B6C.8000908@codemonkey.ws>
In-Reply-To: <4BF45B6C.8000908@codemonkey.ws>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>

On 05/20/2010 12:43 AM, Anthony Liguori wrote:
>
> The JSON specification explicitly says:
>
> "A JSON parser transforms a JSON text into another representation. A 
> JSON parser MUST accept all texts that conform to the JSON grammar.  A 
> JSON parser MAY accept non-JSON forms or extensions."
>
> IOW, we're under no obligation to reject extensions and I can't think 
> of a reason why we should.

At the very least, we should document them.  If the extension doesn't 
add any value but is merely a side effect of the implementation, we 
should remove it.

Examples where this could hurt us:

- we move to a json parsing library, the extension disappears, client breaks
- someone writes a qemu simulator to test managment tool scalability 
(run zillions of fake guests on one machine), client breaks
- someone writes a debug tool that interposes between client and qemu, 
client breaks
- the json specification adds a new form that conflicts with one of our 
extensions [1], we can't use the new form

Being strict in what we accept will reduce our support burden later on.

[1] allowing infinite extensibility like this is irresponsible

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.