MI protocol stuff

[Paul Schlie <schlie at comcast dot net>]

I wonder if a simple resolution to all's concerns may be to consider
adopting some form of a basic MI announcement/negotiation protocol/syntax
in MI2 onward, to both address bob's concerns, and provide the gdb team
with the flexibility to more easily adopt/support/evolve future protocol
variants? Possibly something like:

[plain-text 8-bit asccii encoded]

<mi-vers> :: x[.y[.z]]         ; Major[.Minor[.Patch]] absents of an
                                 optional field implies any sub-version
                                 (i.e. 2 -> 2.x.x, 2.3 -> 2.3.x, etc.)

<mi-list> :: (mi <mi-vers> ...) ; An ordered list of MI versions supported
                                  by the link interface by preference,
                                  where the first listed is preferred, and
                                  considered the present default, until
                                  requested and agreed to otherwise.

Upon link startup, both gdb and the connecting client exchange <mi-list>
announcement/requests, where if both agree on the first listed version,
it is considered to have been adopted; where either may optionally request
to re-designate their preferred MI version, by re-ordering it first in
an <mi-list> message, if the other agrees but is different than their
present default, it sends a correspondingly reordered <mi-list> in response
in confirmation, if the received requested preferred default is the same as
the presently assumed default, no response given as both parties then agree.

Simple example:

GDB   => (mi 3.0.2 2.2 2.1.3) ; GDB (or CLNT) announces its preferences.
CLNT  => (mi 2.2.5 2.1)       ; ClieNT (or GDB) does the same.
GDB   => (mi 2.2.5 3.0 2.1.3) ; GDB (or CLNT) acknowledges the request.
                   
Resulting with both agreeing to MI2.2.5, which may be subsequently modified
at either parties request if a mutually agreeable supported version exists.

Thanks, and best of luck, -paul-