Re: GDB/XMI (XML Machine Interface)

[Bob Rossi <bob at brasko dot net>]

On Tue, Aug 10, 2004 at 04:14:40PM -0400, Bob Rossi wrote:
> Hi,
> 
> As most of you know, I have been writing a front end to GDB called CGDB.
> However, for a while now, I have been a little disappointed with the MI
> interface. In my RFC I have described the problems I have with MI and I
> have proposed a new method of communication between GDB and the front
> end.
> 
> If there is good feedback on this RFC, I will continue research on it,
> filling in details that I thought would be best to wait until after an
> initial acceptance.
> 
> If the RFC is accepted by the community I plan on implementing an
> initial version of the XMI interface in GDB, and programming CGDB to 
> sit on top of GDB. This will at least give the community one open 
> source front end to GDB and an example to prove that the new 
> machine interface works.
> 
> I can't wait to hear your opinions/comments.

Hi,

Well, it seems as if my efforts only brought up enough interest to just 
get a couple of replies. 

Basically, most of you point out that I am interested in changing at a high 
level the development process of the interface between GDB and the front end.
Obviously, switching GDB's output to XML only gains the front ends a simple
way to parse the data. Besides validation, and maybe transformations, it 
basically does nothing else. I have listed some other higher level things, like 
Michael pointed out. These are the things that I feel will make my front end 
successful over the long run. I understand that what makes my front end 
successful might not make everyone's successful, but the union of all these
ideas will make everyone's front end successful. Therefor, I am offering up
at least the minimum amount of work that needs to be done to GDB in order to
make a front end successful, not just now, but in the future also.

   Michael noted some of the things I think a protocol should contain
   . The MI has an insufficient reflective interface.  
   . 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.  
   . Inferior process output mixes with gdb output.

All of these issues are key to what I think a front end should expect from
GDB. However, I realize that none of these issues have anything to do with
XML. XML is just an obvious way to communicate data between to entities.

Jim suggested, 
   1) You can run gdb and use the tty command to send inferior output to a 
separate pty.  
   2) The XML output should just be another ui_out.  

   and some suggestions on commands sent from the front end to GDB.

Nick G suggested,
   Now for the real honesty:  I don't think an XML interface is going to
   fix the real problem.  The real problem is that GDB is not a library. 

Chris F suggested,
   He defiantly didn't see the benefit to switching to XMI, since XML is harder
   for him to understand than MI output.

I don't really know where to go from here. The XML change I think is a no brainer. 
It is a task that every front end writer in the future will be thankful for. Believe me,
no one is interested in parsing the MI output. It is a *complete waste of time*.
Next and more importantly, the versioning is a major hurdle for me in regards to MI. 
I think protocols should always be backwards compatible, it is a necessity for the 
client of the protocol. However, up till now I might be the only one making a big stink 
out of this, and therefor the versions are not backwards compatible. I believe CVS
snapshots and major releases should always adhere to the backwards compatibility test.
For example, I use CGDB with a version of GNAT's GDB and it works because A2 hasn't 
changed. I want to be able to use XMI with a 4 year old GDB, because the software world
is majorly screwed up, and sometimes I find myself having to work with ancient software.

If this document could be modified in any way, I would be more than glad to make an
initial effort at getting GDB/XMI going. I believe that all of the infrastructure for
the MI commands can stay in place, and like Jim said, a new ui_out  could be created.
A re-write from the MI is the worst idea in my opinion. I think that GDB is finally 
maturing a protocol that front end developers can not snicker at. I believe it should just
be modified in some ways and that XML would be a great plus for outputting data.

Finally, the difference between a text based protocol and a libgdb interface is irrelevant
to me. I would personally prefer the text based protocol at this point in time seeing that
there is no libgdb. What stopped the production of that effort? Also, making clients link
to the GDB they want to work with seems like a pain.

My proposal would be to make all of the infrastructure change to the MI code, not new code. 
Add validation, versioning, and maybe a new way besides the tty command to separate 
GDB output and the inferior output. Finally, add a new ui_out that outputs the commands in
XML. Thus, only adding the XML feature completely, otherwise, changing the process's of the 
MI to work the way I am suggesting.

Eagerly awaiting instructions :)

Thanks,
Bob Rossi