From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32339 invoked by alias); 11 Aug 2004 00:17:48 -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 32331 invoked from network); 11 Aug 2004 00:17:47 -0000 Received: from unknown (HELO smtp6.mindspring.com) (207.69.200.110) by sourceware.org with SMTP; 11 Aug 2004 00:17:47 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 1BugoB-0001y7-00; Tue, 10 Aug 2004 20:17:35 -0400 Received: from mindspring.com (localhost [127.0.0.1]) by berman.michael-chastain.com (Postfix) with SMTP id 9D2084B102; Tue, 10 Aug 2004 20:17:49 -0400 (EDT) Date: Wed, 11 Aug 2004 00:17:00 -0000 From: Michael Chastain To: gdb@sources.redhat.com, bob@brasko.net Subject: Re: GDB/XMI (XML Machine Interface) Message-ID: <411965AC.nailAR82WNJ5Y@mindspring.com> References: <20040810201440.GA24186@white> In-Reply-To: <20040810201440.GA24186@white> User-Agent: nail 10.8 6/28/04 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00158.txt.bz2 Interesting idea. Here are my opinions. This is real armchair stuff, I've not an MI expert, but I've had a little experience with XML (my test bed uses XML headers to track the hundreds of configurations that I generate and test). So these opinions are naive. Pro XML: Standard libraries are available for reading XML. This moves one level of parsing out of front end code into a standard library. DTD helps solve the versioning problem. Con XML: MI already exists. XML standardizes some of the lowest levels of the data interchange format. But I get the impression that the problems you have are not at that level. They are really one level up. Problems like: . The MI has an insufficient reflective interface. That is, the front end cannot query GDB and find out the list of supported commands and the format of each command. With XML, gdb could support commands to get the list of supported commands and a DTD for each command. . MI output changes from time to time. Your proposal is to restrict the changes: fields can be added but not removed or modified; commands can be added and old commands deprecated. I think this sort of protocol evolution is XML-neutral, it's the same kind of restrictions whatever the data format. . Inferior process output mixes with gdb output. I don't think XML helps with this at all -- it's a problem at a lower level than the XML level. Either open several streams, or emit some kind of packets on the single stream, with each packet tagged as "gdb output" or "inferior output". XML is not very good for interpolating "inferior output" at random places in the XML stream. >From a higher view, adopting XML would force us to think about these issues. If a program writes XML then it's natural to expect the XML to match some DTD, and then you start thinking about versioning the DTD, and so on. It's a cultural environment where the requirements that come from the front end are a natural part of this environment. As far as I can tell, and I'm no expert on MI, we could do most of these things with the existing MI interface. Separating inferior output from gdb output is a different kind of problem, no matter what the data interchange format. But the reflective interface and the protocol evolution could be done with MI. We could identify the requirements and then make MI meet those requirements, without going to XML data interchange format. Or, conversely, if we're having trouble with MI fields changing too much in cvs gdb, then we're also at risk from the DTD changing too much in an XML-based MI. Michael C