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

[Jim Ingham <jingham at apple dot com>]

Andrew,

On Tuesday, October 1, 2002, at 09:29  AM, Andrew Cagney wrote:

> > Hi, all...
> > The changes from mi0 to mi1 were pretty trivial.  So clients (in my 
> > case Project Builder) can fairly easily accommodate the removal of 
> > the mi0 interpreter.  I am not suggesting that we reinstate that.
> > However, the mi2 is shaping up to be a pretty big change (among other 
> > things, command results are differently reported in toto, as well as 
> > some command results changing format.)  Converting PB from mi1 to mi2 
> > is going to be a lot of work.   And because of its nature, there is 
> > no a priori way to tell what all the clients are - and not all the 
> > clients will closely read the gdb-patches mailing list...
> mi2 is bug fixes on mi1.  However, at the same time it is gaining some 
> of the missing functionality.  Its just that more bugs and more 
> missing functionality are being worked on.  To put it simply, about 
> time!
Well, mi1 was a moving target, so "bug fixes on mi1" is a little hard 
to quantify.  But the change that Keith proposed - which started off 
the bump to mi2 discussion - was to move command result reporting for 
things like -break-insert from the ^done to the gdb event.  This has a 
big effect on how a client uses the mi.

> cf the patch to pr gdb/672 where the output was straight bogus (it 
> contained the equivalent of {name="foo", name="bar", name="baz"}.  
> JeffJ has been asked to preserve the old (broken) behavior.  I should 
> note it was very tempting to not make this request since the old 
> behavior was broken and should have been bug-reported and fixed long 
> long ago.
>
> > Because of this, I am a little nervous at the easy way we are talking 
> > about deleting older versions of the mi.  I think it is our 
> > responsibility to careful, and only release versions of the mi that 
> > we want to support, not the clients of the mi's responsibility to 
> > change their code every time we decide we are tired of supporting the 
> > test cases from one of the other versions we have previously 
> > promulgated...  The mi loses much of its appeal if it means you are 
> > going to have to occasionally rework parts of your client that 
> > already work just fine, or suffer permanent fork-hood for your gdb.
> I was ment to delete mi0 something like a year ago.  I'm running a 
> little late on that one :-)
>
> > I agree with Daniel that we should hold off on declaring a real mi2 
> > till we have something we are willing to support long term.   And for 
> > the mi to be useful, I think we need to stick to only putting out 
> > named versions that we are willing to support.
> Part of the nature of GDB is that it is constantly evolving.  MI is 
> going to be (like it or not) part of that evolution.  Each new GDB 
> release will see enhancements and bug fixes and MI uses will need to 
> be accomodating to that.
This is only partly true.  We are actually pretty conservative about 
changing command output.  We haven't broken annotate for a while, IIRC. 
 The mi is more like the command output, and I think we should have the 
same level of conservatism about this.

> In return for this accomodation GDB are trying to preserve a given MI 
> interface for at least two release cycles.  Part of is the very strong 
> emphasis on testcases and documentation.  If you feel that things are 
> lacking in this area then, perhaphs something to contribute to, is the 
> documentation and testing infrastructure for MI (did the apple 
> droppings contain any new tests?).
No, we haven't worked on this.  It is something we know we need to do, 
but for now we have been using Project Builder as our mi tester (it 
exercises a fair bit of the functionality, and catches most of the 
things we break).

> Over time, the MI interface should also stablize.
I agree.  I am just arguing that we should mark stable points and then 
think hard before we delete them.  Otherwise while it is waiting to 
stabilize, folks will be reasonably a little chary about using it...

Jim
--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer