Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Andrew Cagney <ac131313@redhat.com>]

> I am a little confused here.  One of the design points for the MI is the ability to add information to the commands without requiring a change in the clients (unless, of course, they wanted to use the new information).  That should mean that we have set up a situation where we can change the mi in substantial ways without having to demand that clients rewrite their code to use MI.  Shouldn't that mean that we can go a long way without having to make incompatible changes?  And so, imposing the burden on ourselves of not jerking clients around all the time would not be such a big deal, and perhaps worth the inconvenience it would cause the MI developers?

Yes, that's the theory.  There are always problems though:

- for some commands, their output is simply bogus.  See gdb/672
 > > - var-update syntax is:
   ^done,changelist={name="var3",in_scope="true",type_changed="false",
      name="var2",in_scope="true",type_changed="false"}
Notice how a single tuple contains several "name" fields :-(  JeffJ's 
currently comming up with a patch that will preserve the current behavior.

- some parts of the interface were technically flawed.
The breakpoint event stuff that KeithS changed (but not in a backward 
compatible way :-().  Not fixing this, further entrenches a flawed model 
:-(  The only error in that change was not preserving the old output 
when mi1 :-(

Fixing either of these involves significant change to MI's output, but 
it, I think, is for the better.

> As a client of the MI, this means that in a year or so I have to expect to rewrite code that works just fine, because you have deleted the support for it from gdb; or carry the burden of maintaining mi1 as patches to the gdb sources.  And longer term, I can expect to do this again next year, unless things "stabilize" before then, which they may or may not do.  This doesn't sound appetizing to me.
> 
> The MI is a public interface to gdb - and the only really useful one we offer to external clients who are not Human beings right now.  It has been around in gdb, and we have been using it contentedly, for a couple of years now.  A retroactively stated policy of instability in this interface (including the vanishing of useful variants at odd intervals) seems very unfair to those who have been using it right along, as well as being one which can only slow its uptake in general.

What we're seeing here is the fallout that results from a number of 
players creating localized GDBs.  GDB developers have started looking at 
the underlying problems that Apple and others encountered, and are 
trying to fix them.  Regretably, per above, this is going to need some 
short term change.

It is just a shame that this process wasn't started long ago.

Andrew