From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20957 invoked by alias); 24 Mar 2006 03:27:56 -0000 Received: (qmail 20949 invoked by uid 22791); 24 Mar 2006 03:27:56 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 24 Mar 2006 03:27:54 +0000 Received: from kahikatea.snap.net.nz (p202-124-114-102.snap.net.nz [202.124.114.102]) by viper.snap.net.nz (Postfix) with ESMTP id 7F3E774ACE1; Fri, 24 Mar 2006 15:27:48 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id C9A0288ED; Fri, 24 Mar 2006 15:26:16 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17443.26328.244229.176834@kahikatea.snap.net.nz> Date: Fri, 24 Mar 2006 05:26:00 -0000 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: MI: type prefixes for values In-Reply-To: <20060324024034.GA2853@nevyn.them.org> References: <17427.54333.236860.258115@kahikatea.snap.net.nz> <20060317193243.GB19068@nevyn.them.org> <17435.24954.801098.804532@kahikatea.snap.net.nz> <20060318013113.GA28374@nevyn.them.org> <17435.29362.640036.97752@kahikatea.snap.net.nz> <20060324024034.GA2853@nevyn.them.org> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00263.txt.bz2 > Anyway, I think I'm OK with this change, but I want to track down one > more thing first. OK > Adding the fullname field was considered (as I wrote above) as a > backwards-compatible change. I don't intend on allowing > incompatible changes to sneak into MI2 (well, hopefully...). > MI3 will be ready when it's ready :-) Lets describe in the manual how the (released) protocol might change then to give developers a certain expectation and so that they can guard against those changes: 1) New MI commands may be added. Yes (as front-ends don't need to use them). 2) New fields may be added to the output of any MI command. Yes. 3) The format of field's content e.g type prefix, may change so parse it at your own risk. Yes, in general? 4) The order of fields may change? Shouldn't really matter but it might resolve inconsistencies. And we could add to the list as new cases arise. -- Nick http://www.inet.net.nz/~nickrob