Re: asynchronous MI output commands

["Bjarke Viksoe" <bviksoe@hotmail.com>]

>From: Bob Rossi >
> > You can easily categorize a ^done or ^error response as synchronous.
> > Other responses are more difficult to associate with a command, because
> > they weren't directly issued as the response to a command.
> >
> > > It could output
> > >
> > > -file-list-exec-source-file
> > > %-file-list-exec-source-file
> > > 
>^done,line="26",file="test.c",fullname="/home/bob/cvs/cgdb/cgdb.mi/builddir/test.c"
> > > (gdb)
> >
> > Accomplishing what?  This is synchronous.  It's a response to the
> > previously issued command.  The front end knows exactly what its
> > previously issued command was, I hope.
>
>Hmmm. That's interesting, I was hoping to not need to know what the
>input command was in order to parse and build an ADT for the output. In
>general, I think it would be appropriate if the MI output described
>itself well enough that no other information was needed to understand
>it, including the MI intput command.
>
>...
>
>Thanks,
>Bob Rossi

When I started using the MI a long time ago I assumed the same - that the MI 
output would define to some extent what was asked.
This would make the front-end much more state-less and easy to do.
Unfortunately it does not appear to be the case. I think the general 
suggestion is to make use of the <token> part of the command syntax to allow 
you to match the answer with the question - leaving it up to you to keep 
track of input-parameters, commands and context.

In my case I wish to submit several commands at once and slowly digest the 
answer (over a remote line where the network round-trip is slow). Using the 
<token> is clumsy and doesn't solve the problem of having enough information 
to process the answer without keeping track of the question. Since separate 
components handle the output autonomously, I had to give up tracking a 
command-list, and instead had to make sure only 1 question was lingering - 
thus making the entire solution run much slower than otherwise needed.

I found that commands that return "^value" result-records (such as 
-var-evaluate-expression and -data-evaluate-expression) doesn't carry enough 
information. I don't think a model where the entire command is repeated in 
the output is a desirable design, but at least identifying the question-type 
and its crucial parameters would suffice.

regards
bjarke