MI changes

MI changes

[Bob Rossi]

Hi,

Could I please have a response to this topic? I am being held up on the
development of my project while waiting for this decision.

I propose several changes to MI.

   1. Every MI output command is prefixed with a label saying what type
   of command it is. This is easy for synchronous commands. We will have
   to make a list of asynchronous MI output commands that can be
   documented some where.

      benefit: the front end knows how to deal with the data it was
      given in all circumstances

   2. Because of this new label, all MI output commands of it's type
   will be backwards compatible. Only adding fields and such things are
   allowed. If it is necessary to change the command, a new MI command
   and label will be put in it's place.

      benefit: front ends will be very reliable because they will work
      with new and old GDB's. They will also work with snapshot of GDB
      instead of only major releases.

BTW, this Email does not address MI input commands in any way. This will
be the next step on my list.

Thanks,
Bob Rossi

Re: MI changes

[Andrew Cagney]

> Hi,
> 
> Could I please have a response to this topic? I am being held up on the
> development of my project while waiting for this decision.

I think others have already responded to this proposal with a clear 
rationale for not making a change.  We've already got numeric prefixes 
which are returned with the command result.  Asynchronous output has to 
be self contained.

Andrew

> I propose several changes to MI.
> 
>    1. Every MI output command is prefixed with a label saying what type
>    of command it is. This is easy for synchronous commands. We will have
>    to make a list of asynchronous MI output commands that can be
>    documented some where.
> 
>       benefit: the front end knows how to deal with the data it was
>       given in all circumstances
> 
>    2. Because of this new label, all MI output commands of it's type
>    will be backwards compatible. Only adding fields and such things are
>    allowed. If it is necessary to change the command, a new MI command
>    and label will be put in it's place.
> 
>       benefit: front ends will be very reliable because they will work
>       with new and old GDB's. They will also work with snapshot of GDB
>       instead of only major releases.
> 
> BTW, this Email does not address MI input commands in any way. This will
> be the next step on my list.
> 
> Thanks,
> Bob Rossi
> 

Re: MI changes

[Bob Rossi]

On Fri, Sep 24, 2004 at 06:40:37PM -0400, Andrew Cagney wrote:
> >Hi,
> >
> >Could I please have a response to this topic? I am being held up on the
> >development of my project while waiting for this decision.
> 
> I think others have already responded to this proposal with a clear 
> rationale for not making a change.  We've already got numeric prefixes 
> which are returned with the command result.  Asynchronous output has to 
> be self contained.

Yes, I understand that numeric prefixes take account for the synchronous
commands. However, what does the sentence "Asynchronous output has to be
self contained" mean? I still think that the problem exists for
asynchronous commands, and this is one of the reasons I brought the
problem up.

The big issue here that everyone seems to be avoiding is how we should
deal with versioning of the MI commands. You yourself stated that GDB/MI
should move to a versioning scheme where it is capable of working with
front ends that are not tied to a particular version of GDB. It should
also work with "snapshots" of GDB. This means that GDB should be self
documenting at any given point about what type of MI output and MI input
commands it receives/sends. Not just one big MI level.

My recommendation to add the label's was a way for GDB to tell the front
end what version of an MI output command it is sending. We could then 
add a new MI output command to GDB that tells the front end all of the 
capable MI output commands that the current version of the GDB your 
dealing with supports. The same could be true for MI input commands. 

Honestly, I don't think the current MI interface supports front ends
that will work with multiple versions of GDB and I am trying to change
that. I don't want to start hacking on CGDB until I know that it will
work reasonably in several different environments, with several
different version of GDB.

If my solution isn't good, can we come up with some other suggestions?

> >I propose several changes to MI.
> >
> >   1. Every MI output command is prefixed with a label saying what type
> >   of command it is. This is easy for synchronous commands. We will have
> >   to make a list of asynchronous MI output commands that can be
> >   documented some where.
> >
> >      benefit: the front end knows how to deal with the data it was
> >      given in all circumstances
> >
> >   2. Because of this new label, all MI output commands of it's type
> >   will be backwards compatible. Only adding fields and such things are
> >   allowed. If it is necessary to change the command, a new MI command
> >   and label will be put in it's place.
> >
> >      benefit: front ends will be very reliable because they will work
> >      with new and old GDB's. They will also work with snapshot of GDB
> >      instead of only major releases.
> >
> >BTW, this Email does not address MI input commands in any way. This will
> >be the next step on my list.
> >
> >Thanks,
> >Bob Rossi
> >