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

[Jim Ingham <jingham at apple dot com>]

Andrew,

On Tuesday, October 1, 2002, at 01:25  PM, Andrew Cagney wrote:

> > 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.
> One of the motivations behind the MI output was that a parser could be 
> written in a way that allowed it to discard anything it didn't 
> recognize.
>
> For instance: additional events, or additional output fields should 
> both simply be discarded.  They shouldn't be viewed as MI changes.
>
> The thing that is triggering mi2 is the changes to actual responses 
> (breakpoints as you pointed out but also others.).
>
> Anyway, at the time of each GDB release, a decision should be made 
> about freezing the current MI interface and starting a new one.  Here, 
> we've frozen mi1 and moved onto mi2's development.  At some point in 
> the future mi2 will be frozen and development will move to mi3 (I 
> strongly suspect it will be pretty quick - 5.4/6.0).  After a freeze, 
> the old syntax should hang around for a limited period of time.
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?

> The pratical translation of this is  ``how long before the mi1-*.exp 
> files can be deleted''?  My guess is two releases - here 5.3 and 
> 5.4/6.0. That means that 5.5/6.0 (in roughly a year) there will be 
> released a GDB  that doesn't support "mi1" -- for GDB I think that is 
> a long time!
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.


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