From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27846 invoked by alias); 6 Oct 2004 16:31:33 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 27835 invoked from network); 6 Oct 2004 16:31:32 -0000 Received: from unknown (HELO lakermmtao11.cox.net) (68.230.240.28) by sourceware.org with SMTP; 6 Oct 2004 16:31:32 -0000 Received: from white ([68.9.64.121]) by lakermmtao11.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041006163131.EAJL5156.lakermmtao11.cox.net@white>; Wed, 6 Oct 2004 12:31:31 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CFEhP-0003Bq-00; Wed, 06 Oct 2004 12:31:31 -0400 Date: Wed, 06 Oct 2004 16:38:00 -0000 From: Bob Rossi To: Eli Zaretskii Cc: nathanw@wasabisystems.com, gdb@sources.redhat.com Subject: Re: Bumping MI protocol Message-ID: <20041006163131.GB12213@white> Mail-Followup-To: Eli Zaretskii , nathanw@wasabisystems.com, gdb@sources.redhat.com References: <20041006010100.GA10896@white> <20041006111436.GA11747@white> <01c4ab9d$Blat.v2.2.2$923860c0@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c4ab9d$Blat.v2.2.2$923860c0@zahav.net.il> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00131.txt.bz2 On Wed, Oct 06, 2004 at 02:10:09PM +0200, Eli Zaretskii wrote: > > Date: Wed, 6 Oct 2004 07:14:36 -0400 > > From: Bob Rossi > > Cc: GDB > > > > Exscuse me for being frank, your statements about this question are foolish. > > I, for one, don't think Nathan's comments are foolish. As a volunteer > project, we shouldn't waste too much time discussing hypothetical > issues. Either one of you, please describe to me which of these questions is foolish, and I will clearly explain to you why I need to know this information in order to build a front end. 1. Besides an MI command that has been changed in an incompatible way, or the actual MI output syntax changing, does the MI version get bumped for other reasons? 2. Can the conditions for bumping the MI version be enumerated? 3. Can this information be documented for all to easily understand? 4. Can a front end developer find all of the functions available to a specific version of an MI protocol from the documentation? > > Nathan, how could a front end implement an MIX protocol if it doesn't > > know what functions that protocol provides? > > No one requires a front end to implement support for features that are > introduced by GDB versions released after the front end is released. > The only way for a front end to support new features is to track GDB > development, and check the GDB and MI versions to know what commands > are safe to use. > > Put it differently, even if the MI version would be incremented each > time a new command is added (which IMHO would be an unwise policy), > you would need an update for the front end to support that command. I also do not think it would be a good idea to bump the version because of new commands. I am asking because it's not documented anywhere. If you want the questions to stop, maybe you will see that there is not enough information avaiable for front end developers to figure these thngs out. Thanks, Bob Rossi