Re: probing GDB for MI versions

Paul Koning
2004-10-06T17:48:00Z

>>>>> "Bob" == Bob Rossi <Bob> writes:

>> > Is this the general feel of the community?
>>
>> Well, it's not what I feel, as I hope I've explained patiently
>> above. I wouldn't care to speak for the community at large, but I
>> would be surprised if anyone else felt that it was wrong to
>> generate a parser from the MI output syntax. What I feel is wrong
>> is your assumption that a generated parser is the only possible
>> means of processing plain ascii human readable text for the
>> purpose of finding and extracting a single integer value.

Bob> I guess the bottom line is, I already have a parser that is
Bob> capable of dealing with a specific version of MI's output. I
Bob> don't want to start up MI with an adhoc parser, just to figure
Bob> out what real parser I should use. This seems not correct to me,
Bob> and I guess it's the issue to deal with.

Bob, that actually IS correct and the conventional way to handle
things. In typical protocol design, the conversation starts with a
message that carries version information. The protocol state machine
initially comes up in a state where it expects that message and knows
how to find the version information. Once it knows that, it flips to
the state machine for that version.

Note that the "ad hoc" part typically only involves one or two
messages and often only a small part of the content of those
messages. For example, the initial message might be a "create
connection" message, carrying dozens of fields one of which is a
version number. The first step is to find that version number; after
that is known, all the rest including the full parse of that initial
message can be done by the full parse machinery.

(Alternatively, there might be a combined state machine -- in your
notation, that would be a grammar for the union of MI1 and MI2, with
condition checking on the version number to forbid certain production
rules. That may work for some protocols; I doubt it's a sensible
answer for MI.)

paul