RE: asynchronous MI output commands

[Alain Magloire <alain at qnx dot com>]

> Daniel Jacobowitz
> 
> On Sun, May 07, 2006 at 08:29:35PM -0400, Bob Rossi wrote:

....
> > Yes, I agree, if I knew the MI input command, I could use that to
> > determine what type of command I was looking at. If I won't be allowed
> > to add the command to the output record, then this is what I will do.
> >
> > However, I would like to be able to do this with out knowing the MI
> input
> > command. First, it makes the code more modular that takes the MI output
> > and turns it into something meaningful. Second, it's easy to gather a
> > bunch of MI output commands from the test suite or from FE user's with
> > FE problem, and parse just that output. Third, it validates that what
> > the user requested is what the user is getting. It is possible that the
> > FE and GDB could get mixed up I'm assumming.
> 
> You're trying to turn a response into a meaningful message without
> knowing what it's a response to.  I just don't see the benefit of this;
> although people keep telling me it's harder than I understand, I
> still haven't seen an example that I consider plausible.
> 

Right, 8-).  I think folks writing front-ends go naturally in that direction
because it is simply easier and it decouples the code so we do not need to
synchronize between commands and response.  Basically you can have one
thread posting commands and another parsing response.  But that said, I have
to agree with you, it is not a necessity and in reality we will need to
associate response with a command or a caller i.e. to update a tree view or
whatever viewer that initiate the sequence.

> It's easy to gather output from e.g. the testsuite, true.  But it's
> equally easy to record the commands - just about everything is going to
> go through mi_gdb_test, or you could even write a proxy between the
> testsuite and GDB which logged, or add the logging to GDB directly.  I
> know Eclipse's MI protocol log includes the commands it sent.
> 
> Your third point is valid, but does not seem particularly important to
> me.  If it's wrong, it's wrong.  GDB would just have to stitch the
> command name on at the end right before outputing the result record,
> so that wouldn't gain you much at all.
>

MI offers a simple way to associate response and commands, by tagging the
commands the ^done will come back with the associated tag.

> > Anyways, Daniel, thanks for taking time out of your busy schedule to
> > think about this issue. If you simply don't want something like this in
> > MI right now, I'll find a way to match the input with the output.
> 
> I'm not supreme dictator of this stuff; someone else is welcome to step
> in and disagree.  I'm just not convinced, either.
> 

OOB messages are important and are not necessarily associated with a
command, they may be side effects of something the front-end did not
initiate, for example loading libraries, creating threads etc ..

As you decoupling completely responses form command, may look like a good
idea only on the surface.