From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21960 invoked by alias); 21 Aug 2004 13:34:03 -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 21937 invoked from network); 21 Aug 2004 13:34:02 -0000 Received: from unknown (HELO legolas.inter.net.il) (192.114.186.24) by sourceware.org with SMTP; 21 Aug 2004 13:34:02 -0000 Received: from zaretski ([80.230.144.169]) by legolas.inter.net.il (MOS 3.4.6-GR) with ESMTP id CIE99751 (AUTH halo1); Sat, 21 Aug 2004 16:33:44 +0300 (IDT) Date: Sat, 21 Aug 2004 13:34:00 -0000 From: "Eli Zaretskii" To: Bob Rossi Message-ID: <01c48782$Blat.v2.2.2$ea24e040@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: gdb@sources.redhat.com, cagney@redhat.com, ezannoni@redhat.com, fnasser@redhat.com In-reply-to: <20040821123440.GA7138@white> (message from Bob Rossi on Sat, 21 Aug 2004 08:34:40 -0400) Subject: Re: GDB/XMI (XML Machine Interface) Reply-to: Eli Zaretskii References: <20040820103420.340A64D400C@stray.canids> <20040820125443.GB5703@white> <20040820183447.GA21565@nevyn.them.org> <20040820184900.GA5806@white> <20040820185159.GA22481@nevyn.them.org> <20040820192458.GB5806@white> <20040820194224.GA24407@nevyn.them.org> <20040820195928.GA6372@white> <01c48768$Blat.v2.2.2$a38a12a0@zahav.net.il> <20040821123440.GA7138@white> X-SW-Source: 2004-08/txt/msg00270.txt.bz2 > Date: Sat, 21 Aug 2004 08:34:40 -0400 > From: Bob Rossi > > These designated individuals either are busy or refuse to even discuss > the topic at hand. I was talking about code submitted for inclusion, not about ideas. > > I'm neither Andrew nor Elena nor Fernando, but I will try to summarize > > the impression I got from this discussion so far: your proposal > > mentioned several problems with MI, but most of those problems can > > (and IMHO should) be solved without ditching MI, and the effort to > > solve those problems with XMI is not going to be smaller. One notable > > example of such problems is back compatibility, but there were others. > > I believe that making GDB output XML would be trivial. I don't think so, but that was not what I meant to say in the portion you cited. I meant to say that to overcome most of the problems you mentioned (saying that they originate from MI usage), it will not be enough just to teach GDB speak XML. Overcoming those problems will need additional effort, regardless of whether GDB speaks XML or not. Others explained in detail why is that so, but if you want to discuss it again, let's take the back compatibility issue and analyze it. > > I agree that it would be a Good Thing if GDB would come with a > > read-to-use MI parser library. If you care about easing the pains of > > a GDB front-end programmer, then the project of writing such a parsing > > library should sound important to you. But since you said quite > > explicitly that you are not interested in such a project, > > I am going to have to write an MI parser, if GDB refuses to simplfy it's > output. Then how about doing what I believe was proposed in this thread: write an MI parsing library that every front-end programmer could use henceforth? I thought you said that you were not interested in doing that, but I cannot understand why, given the fact that you will be the very first user of such a library. > I care nothing about XML. As I say it over and over again. If XML is > outputted by GDB, it could be binary for all I care, NO parser has to be > written. The job has already been done. > > I would not have to write a parser. > I would not have to write a library. > No one would. > Ever. That might be true, but then we will need to solve the problem of changes in the XMI in some way, be it via DTD or otherwise. Producing a DTD and maintaining it in sync with the modifications in XMI is a maintenance burden we currently don't have. Also, the effort to teach GDB speak XML is a non-trivial effort, and maintaining that together with MI and annotations (as we cannot simply drop existing interfaces overnight) is in itself a burden. So, more generally, one can say that switching to XML does not miraculously remove the need to invest some effort when we change the output syntax. Therefore, we need to weight the advantages and disadvantages of your proposal, which is what this discussion was all about, I believe. So it's not that people here are somehow prejudiced against XML, they simply think that the benefits from going XML are not significant enough, while most of the problems that exist with MI will not be solved by switching to XML.