Re: GDB/XMI (XML Machine Interface)

[Michael Chastain <mec.gnu@mindspring.com>]

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