Re: breakpoint extension for remote protocol, take II

[Jim Blandy <jimb@cygnus.com>]

> When I suggested a 'escape' command prefix I had in mind two groups.
> One who will work with the GDB/remote protocol mainatainers to come up
> with a suitable/acceptable specification for their extensions; And the
> other that just wants to do their own thing.  The escape command is
> for that second group.  It guarantees that future GDB/remote protocol
> versions won't interfere with their extensions, and a the same time
> ensures that changes the GDB/remote protocol won't be sidelined by 
> some extension that no one bothered to tell the maintainers about.
> 
> Jim> If we're going to establish a policy, it should be one that
> Jim> allows a smooth transition of packets' status from "experimental"
> Jim> to "standard".  By `smooth', I mean that the packet itself
> Jim> shouldn't have to change simply because we've acknowledged it as
> Jim> widely useful.
> 
> Given the model I outlined above, this would only occur if someone in
> the second group had: 1) a change of heart/philosophy and wanted to
> contribute what had been a proprietary command, and 2) that that
> command was generally useful.  Perhaps I'm being unreasonable, but I
> don't feel I have any obligation to those users to integrate their
> command into the protocol unchanged, especially if there is a more
> general/elegant scheme to do the same thing.  I believe that to do
> otherwise rewards rogue behavior.

Right.  Like writing a free debugger.  "Rogue" seems hard to
distinguish from "independent-minded."

I don't think we accomplish anything by making it hard for
independently developed extensions to become official.

Allocating prefixes to developers on request accomplishes your goal
above --- avoiding interference between the GDB maintainers and
independent projects --- and also makes it easy (a no-op, as far as
the code is concerned) for rogue developers to return to the fold.

And finally, it doesn't seem like much more work.  Maybe others
disagree.