RE: asynchronous MI output commands

[Alain Magloire <alain@qnx.com>]

> 
> Daniel Jacobowitz wrote:
> 
> > On Sun, May 07, 2006 at 11:09:51PM +0200, Bjarke Viksoe wrote:
> >> 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.
> >
> > If I were writing a front-end, I would have an arbitration layer which
> > sent questions to GDB and received answers.  The answers will come back
> > one at a time, in the same order the questions were asked.  If you send
> > two -var-evaluate-expression commands, you'll get back two answers, in
> > that same order.
> >
> > Am I missing something?  Is there a reason that this isn't enough?
> 
> For the record, that's basically what I have in KDevelop. There's command
> queue, and commands are sent to gdb one-at-a-time, and responses come
> exactly in the same order. Remembering the last issued command (i.e.
> instance of GDBCommand class internal to KDevelop) makes it possible to
> route the response back to the original command.
> 
> I'm don't quite understand the problems being discussed in this thread.
> It's
> not apparent why one has to know the type of the last command while
> parsing, and if so, why remembering the last command is bad idea.
> 
> It's hard to believe that response from MI can be useful without knowing
> the
> last issued command. Say, response from -data-evaluate-expression is
> useless if you don't know what part of frontend wants that data --
> evaluating expression is used in many use cases. So, you need to associate
> extra data with commands anyway.
>

I agree, the example that comes to my mind is "next", "step", "finish",
"continue" etc ...  To do some optimization front-ends will probably need to
know the last command issue (for example clearing all the variable state in
a variable view for "continue").

Maybe I'm mistaken but I have the impression, looking at the thread, some
folks are confusing OOB and synchronous response that comes after issuing a
command.

An implementation of MI could be made to be totally asynchronous if all
response could be tag to a matching command.  OOB should not be paired to
any commands.