From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11098 invoked by alias); 18 Dec 2006 19:56:44 -0000 Received: (qmail 11081 invoked by uid 22791); 18 Dec 2006 19:56:43 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao06.cox.net (HELO eastrmmtao06.cox.net) (68.230.240.33) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Dec 2006 19:56:28 +0000 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao06.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20061218195625.LEIU19510.eastrmmtao06.cox.net@eastrmimpo01.cox.net>; Mon, 18 Dec 2006 14:56:25 -0500 Received: from black ([70.181.32.198]) by eastrmimpo01.cox.net with bizsmtp id 0KvK1W00F4GV2Jm0000000; Mon, 18 Dec 2006 14:55:19 -0500 Received: from bob by black with local (Exim 4.62) (envelope-from ) id 1GwOb1-0007NK-Vj; Mon, 18 Dec 2006 14:56:23 -0500 Date: Mon, 18 Dec 2006 19:56:00 -0000 From: Bob Rossi To: Nick Roberts Cc: Vladimir Prus , gdb@sources.redhat.com Subject: Re: MI fine-grained versioning Message-ID: <20061218195623.GC27512@cox.net> Mail-Followup-To: Nick Roberts , Vladimir Prus , gdb@sources.redhat.com References: <200612181835.34025.vladimir@codesourcery.com> <20061218153921.GY20942@cox.net> <17798.61527.726165.630956@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17798.61527.726165.630956@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.12-2006-07-14 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-12/txt/msg00171.txt.bz2 On Tue, Dec 19, 2006 at 08:47:35AM +1300, Nick Roberts wrote: > > > How about adding new MI command that returnes list of supported > > > fine-grained features. For example: > > > > > > -list-features > > > ^done,result=["frozen_variables","info_path_expression"] > > > > > > The MI manual would contain a section listing all feature names and > > > briefly documenting them. > > > > Great idea! > > > > There are a few gothcha's. For instance, each command can support > > several parameters, so you might want to report on that. But more > > tricky, is when a command adds an output field that the front end cares > > about. > > In the manual we already explain that front ends should be able to handle > extra fields in MI output. The front end would need to do this just > to handle -list-features. Yes, this should be obvious. I'm suggesting that the front end might rely on a particular field to be sent from an MI command to consider it a valid 'version'. Anyways, a good solution to this problem was already given on the list. Bob Rossi