Re: MI: type prefixes for values

[Daniel Jacobowitz <drow at false dot org>]

On Sat, Mar 18, 2006 at 03:38:42PM +1300, Nick Roberts wrote:
>  > I don't think it makes a difference - it could confuse consumers of MI2
>  > anyway - that's all I'm worried about.
> 
> I think it means its generally less likely to make a difference.  In Emacs, I
> just take the value of the field amd insert it in the appropriate window at
> the appropriate place.  Thats why the type currently gets duplicated in the
> locals window.  Removing the type prefix just removes that duplication, I
> don't have to make any changes to the lisp code in Emacs.  Adding a field,
> however, might break my parser if I'm not expecting it.
> 
> However, perhaps you're thinking specifically of Eclipse.

No, it was just the only one I had handy to test.

I'm unsympathetic if adding a new field breaks your parser; MI
is deliberately arranged so that consumers can ignore new fields
that they don't understand.

Anyway, I think I'm OK with this change, but I want to track down one
more thing first.

>  > > Since there are likely to be many more changes to MI, I suggest that when
>  > > we start making changes for mi3 only, the default remains at mi2.  This
>  > > will allow a period of development for mi3 during which changes can be
>  > > made more freely.  It could then be made the default level after it has
>  > > stabilised.
>  > 
>  > Yes, this is already how we document -i=mi to work.  It's the last
>  > finalized version of the protocol.
> 
> But there have been many changes to mi2, notably adding the fullname field
> in several places, since it became the default level.  I'm just suggesting
> that we don't have mi4, mi5, mi6 etc because it gets too complicated.

Adding the fullname field was considered (as I wrote above) as a
backwards-compatible change.  I don't intend on allowing
incompatible changes to sneak into MI2 (well, hopefully...).
MI3 will be ready when it's ready :-)

-- 
Daniel Jacobowitz
CodeSourcery