From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54867) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T4DDa-0007iX-5O for qemu-devel@nongnu.org; Wed, 22 Aug 2012 11:51:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T4DDU-00037u-Bp for qemu-devel@nongnu.org; Wed, 22 Aug 2012 11:51:42 -0400 Received: from paradis.irqsave.net ([109.190.18.76]:34243) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T4DDU-00037W-1F for qemu-devel@nongnu.org; Wed, 22 Aug 2012 11:51:36 -0400 Date: Wed, 22 Aug 2012 17:51:26 +0200 From: =?iso-8859-1?Q?Beno=EEt?= Canet Message-ID: <20120822155126.GD26403@irqsave.net> References: <1345639535-8822-1-git-send-email-benoit@irqsave.net> <1345639535-8822-2-git-send-email-benoit@irqsave.net> <5034E6A2.7060900@redhat.com> <20120822143221.GC26403@irqsave.net> <5034F306.7050602@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <5034F306.7050602@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH V4 1/2] qapi: Add SnapshotInfo and ImageInfo. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: =?iso-8859-1?Q?Beno=EEt?= Canet , aliguori@us.ibm.com, =?iso-8859-1?Q?Beno=EEt?= Canet , stefanha@linux.vnet.ibm.com, qemu-devel@nongnu.org, pbonzini@redhat.com, xiawenc@linux.vnet.ibm.com Le Wednesday 22 Aug 2012 =E0 08:56:06 (-0600), Eric Blake a =E9crit : > On 08/22/2012 08:32 AM, Beno=EEt Canet wrote: > >> Since we have two fields named *-nsec, it might be worth clarifying = that > >> date-nsec is merely the fractional portion to be combined with date-= sec > >> (always less than 1000000000), while vm-clock-nsec includes seconds = if > >> the drift is that large. > >> > >> For that matter, should we even be exposing things in this manner? = I > >> know the internal struct has seconds and nanos separate for date, > >> because it maps to struct timespec; but why can't we combine them in= to > >> one giant number for JSON? > >=20 > > Wouldn't people working with low level language be annoyed after pars= ing > > this JSON to have to split this combined number in two parts to fit > > them back into struct timespec ? >=20 > Perhaps, in which case, why don't we present vm-clock-nsec via two > fields of seconds and fraction, for the same reasoning? I'll do that. > My point is > that we have two different bike shed colors showing in this one API, bu= t > I would prefer we be consistent and pick just one (as to _which_ color, > I can be persuaded either way). >=20 > --=20 > Eric Blake eblake@redhat.com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org >=20