Letters reserved for future use

Letters reserved for future use

[Jim Blandy]

In (gdb)Remote Serial Protocol, every upper- and lower-case letter
that is not given a meaning is marked individually as "reserved for
future use".  This is kind of dopey.  Could we just have one remark at
the top that says that all upper- and lower-case letters not defined
there are reserved for future use?

What should people looking to make vendor-specific extensions to the
protocol do?  Are they required to stay within the general query /
general set commands, with a vendor prefix?

Re: Letters reserved for future use

[Eli Zaretskii]

> Date: Mon, 14 Nov 2005 17:06:32 -0800
> From: Jim Blandy <jimb@red-bean.com>
> 
> In (gdb)Remote Serial Protocol, every upper- and lower-case letter
> that is not given a meaning is marked individually as "reserved for
> future use".  This is kind of dopey.  Could we just have one remark at
> the top that says that all upper- and lower-case letters not defined
> there are reserved for future use?

Yes, please do that.

Re: Letters reserved for future use

[Daniel Jacobowitz]

On Mon, Nov 14, 2005 at 05:06:32PM -0800, Jim Blandy wrote:
> In (gdb)Remote Serial Protocol, every upper- and lower-case letter
> that is not given a meaning is marked individually as "reserved for
> future use".  This is kind of dopey.  Could we just have one remark at
> the top that says that all upper- and lower-case letters not defined
> there are reserved for future use?

What Eli said :-)

> What should people looking to make vendor-specific extensions to the
> protocol do?  Are they required to stay within the general query /
> general set commands, with a vendor prefix?

That's what I've done in the past.  Well, I've also done a certain
amount of just Making Stuff Up, but that's not what I recommend when
people ask me :-)

A reserved "long command" prefix that isn't in the query namespace
might help aesthetically, but would offer no technical value.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Letters reserved for future use

[Jim Blandy]

On 11/14/05, Daniel Jacobowitz <drow@false.org> wrote:
> A reserved "long command" prefix that isn't in the query namespace
> might help aesthetically, but would offer no technical value.

Isn't that what 'v' is allegedly for?

The whole thing about using organizational names in packet formats, as
recommended for the query packets, seems a bit like overengineering. 
If we're responsive, it should be enough for people to simply post
here saying that they've defined a 'u' packet that does thus-and-so. 
Even if we don't like the packet, we can at least act as an ad-hoc
"assigned numbers authority" and note that it's been used somewhere.

Re: Letters reserved for future use

[Daniel Jacobowitz]

On Tue, Nov 15, 2005 at 01:09:34AM -0800, Jim Blandy wrote:
> On 11/14/05, Daniel Jacobowitz <drow@false.org> wrote:
> > A reserved "long command" prefix that isn't in the query namespace
> > might help aesthetically, but would offer no technical value.
> 
> Isn't that what 'v' is allegedly for?

Oh yeah, forgot about that.  We could document the vendor prefix for
'v' too.

> The whole thing about using organizational names in packet formats, as
> recommended for the query packets, seems a bit like overengineering. 
> If we're responsive, it should be enough for people to simply post
> here saying that they've defined a 'u' packet that does thus-and-so. 
> Even if we don't like the packet, we can at least act as an ad-hoc
> "assigned numbers authority" and note that it's been used somewhere.

Except then they have to synchronize with us about their uber-sekrit
ports.  I think the vendor prefixes are a good idea.

-- 
Daniel Jacobowitz
CodeSourcery, LLC