Re: MI rules

[Fabian Cenedese <Cenedese@indel.ch>]

>> How are the existing frontends doing it then? Do they just wait after
>> a sent command until they receive a reply and take it as the one they're
>> looking for?
>
>Well part of the problem I see is with asyncrhonous MI output commands.

That's the main problem I'd say. If the whole communication was
synchronous you'd exactly know what answer is coming and not
need any labeling.

>How is the front end supposed to understand what the data it just
>recieved was. It doesn't even know what type of mi output command it is. 
>So, after it is parsed and put in a parse tree, I don't see a
>way for the front end to say, "Get the data out of this command that I
>care about". It first needs to understand what type of mi output command
>it just recieved. If it knows that, it can actually walk the parse tree
>to get the data it needs.

I was just wondering what commands you're parsing after looking into
mi/mi-cmds.c. Am I seeing right that over half of the mi commands
are not implemented yet?

>Otherwise if it doesn't know that, you end up in a situation where you
>   1. parse the tree.
>   2. walk the tree to guess what kind of command you just received
>      ( can only imagine what kind of maintenence nightmare this is )
>   3. actually walk the tree to get the data you need, once you know
>      what kind of mi output command you have.
>
>This ends up making the parse walk the tree twice. IMO, GDB already
>knows what kind of MI output command it is sending, so it should just
>tell the front end as part of the mi output command. This would solve
>several problems that I am facing.

Yeah, a simple ^done can come from a lot of commands :)

Thanks

bye  Fabi