From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40623) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ca13S-0000GY-4z for qemu-devel@nongnu.org; Sat, 04 Feb 2017 09:11:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ca13R-0001Qb-7k for qemu-devel@nongnu.org; Sat, 04 Feb 2017 09:11:06 -0500 Date: Sat, 4 Feb 2017 22:10:56 +0800 From: Fam Zheng Message-ID: <20170204141056.GB15362@lemon> References: <87bmukmlau.fsf@dusky.pond.sub.org> <20170204122150.GA15362@lemon> <871sve13l4.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871sve13l4.fsf@dusky.pond.sub.org> Subject: Re: [Qemu-devel] Non-flat command line option argument syntax List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Kevin Wolf , Peter Krempa , qemu-devel@nongnu.org, qemu-block@nongnu.org On Sat, 02/04 14:35, Markus Armbruster wrote: > Fam Zheng writes: > > > On Thu, 02/02 20:42, Markus Armbruster wrote: > >> === Comparison === > >> > >> In my opinion, dotted keys are weird and ugly, but at least they don't > >> add to the quoting mess. Structured values look better, except when > >> they do add to the quoting mess. > >> > >> I'm having a hard time deciding which one I like less :) > >> > >> Opinions? Other ideas? > > > > Here's my poor attempt: > > > > The dotted syntax, as the simpler of two, can cover everyday use very well. If > > we introduce an "@reference" extension to it which can help the expresiveness, > > we can have a hybrid solution. It's not the cleanest interface and syntax, but > > escaping, nesting and quoting can all be divide-and-conqured in their optimal way. > > What I'm imagining is something like: > > > > -json "id=children0,text=[ > > { 'driver': 'null-co://' }, > > { 'driver': 'null-co://' }, > > { 'driver': 'null-co://' } > > ]" \ > > -dot \ > > id=quorum0,driver=quorum,read-pattern=fifo,vote-threshold=1,children=@children0 \ > > -drive if=virtio,id=primary-disk0,driver=qcow2,file=@quorum0 > > > > IOW "-json" and "-dot" define options that is intended to be referenced from > > other dotted keys (quorum0 uses children0, and in turn primary-disk0 uses > > quorum0). > > > > Note: "-dot" here could be replaced with a -blockdev in this specific case but > > I'm demostrating it just in case it is useful generically. > > > > Fam > > KEY=@REF for references creates the same issue as KEY=[VALUE,...] for > arrays: you need to know the type of KEY to decide whether @REF is a > reference or a string, unless we outlaw strings starting with '@'. > > Not a show-stopper, but it does preclude a design where a simple parser > feeds into a type-aware visitor, which is how the JSON -> QObject -> > QAPI pipeline works. > > If you get creative in the VALUE part, you complicate the parser and/or > need to add quoting. > > If you get creative in the KEY part, you need to restrict valid names. How about KEY@=REF? Fam