This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: GDB/XMI (XML Machine Interface)
- From: Michael Chastain <mec dot gnu at mindspring dot com>
- To: gdb at sources dot redhat dot com, bob at brasko dot net
- Date: Tue, 10 Aug 2004 20:17:48 -0400
- Subject: Re: GDB/XMI (XML Machine Interface)
- References: <20040810201440.GA24186@white>
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