From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21350 invoked by alias); 8 Oct 2004 12:05:04 -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 21338 invoked from network); 8 Oct 2004 12:05:01 -0000 Received: from unknown (HELO lakermmtao01.cox.net) (68.230.240.38) by sourceware.org with SMTP; 8 Oct 2004 12:05:01 -0000 Received: from white ([68.9.64.121]) by lakermmtao01.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041008120501.IBHB19326.lakermmtao01.cox.net@white>; Fri, 8 Oct 2004 08:05:01 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CFtUa-0004A4-00; Fri, 08 Oct 2004 08:05:00 -0400 Date: Fri, 08 Oct 2004 13:17:00 -0000 From: Bob Rossi To: Fabian Cenedese Cc: gdb@sources.redhat.com Subject: Re: Bob's MI objective Message-ID: <20041008120500.GA15978@white> Mail-Followup-To: Fabian Cenedese , gdb@sources.redhat.com References: <41659659.2030005@gnu.org> <416451B0.3060306@gnu.org> <20041006212652.GB13271@white> <41647352.50603@gnu.org> <20041007163122.GC14573@white> <41659659.2030005@gnu.org> <5.2.0.9.1.20041008085113.01d8eb60@NT_SERVER> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.0.9.1.20041008085113.01d8eb60@NT_SERVER> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00252.txt.bz2 On Fri, Oct 08, 2004 at 08:56:19AM +0200, Fabian Cenedese wrote: > > >> >Understood, here is what I am hoping for at a minimum. > >> > > >> > * GDB supports at least 1 MI protocol for an official release. > >> > Supporting multiple MI protocols would be better for me, but > >> > not a requirement. If GDB could support multiple protocols it > >> > would improve the chances of a given front end working with a > >> > given GDB. > >> > >> But by "support" what do you mean - even a dictionary definition. GDB > >> includes at least one MI implementation, but that says nothing about how > >> well it is either implemented or supported. > > > >That's a good question. > > > >Well, by support I simply mean, GDB is officially saying that a > >particular MI protocol is implemented as it should be, that it is tested > >to make sure that it works to the best of the GDB developers knowledge and > >that it is safe to use by front ends. > > > >I am assuming that MI protocols in development ( right after a version > >bump, but before a major release ) is considered unsupported. By this I > >guess I mean that it should not be used by front ends until it is > >stable. Maybe a better word for "support" in this context is "stable". > > I think the implementation grade is quite important. Though mi2 is > considered now the official and stable mi version I find that half of it > is unimplemented which makes it somehow useless for me. From > this point of view I'd say mi2 is the development version. > (And yes, I'm not only complaining, I have started implementing some > of the missing mi functions.) Yes, I understand what you mean here, however, it is a slightly different problem. I am strictly calling an MI protocol a "development version of MI" if the MI output syntax has not been nailed down ( I've got the hammer ) for an official release. I know there are other reasons why a version of MI could be under development, I am just picking on this one case. I've already described the problem were GDB is released with a stable MI protocol. Then development begins for the next release. A backwards incompatibility happens and the MI version is bumped and the MI output syntax changes. Before the next release another incompatible change can occur and the MI output syntax could change again without a version bump. For this reason, a front end could never communicate with all of these MI protocols ( different grammars ), until a release has been made and the protocol syntax is stable. Even though I might be asking hypothetical questions, I was trying to determine what things would cause the MI protocol to get bumped, so we could figure out what constitutes a development version and what is a stable version. This is why I asked if adding new functions bumps the version, however, several people suggested it shouldn't. Thanks, Bob Rossi