Re: [rfc / remote protocol] Remote shared library events

[Daniel Jacobowitz <drow@false.org>]

On Wed, May 16, 2007 at 03:58:52PM -0700, Jim Blandy wrote:
> It seems odd to me that it's an @var{n} that distinguishes the reason
> for the stop; the @var{AA}, the @var{r}, and any other @var{r}:@var{n}
> pairs are essentially meaningless.  I'd rather see an entirely new
> stop reply packet type --- 'L', say --- with subsequent name/value
> pairs, like those in a q[fs]DllInfo packet's 'm' response.

I don't know why you say they're meaningless.  @var{AA} is unused, but
@var{r} describes the exact reason for the stop (which library was
loaded or unloaded), and other @var{r}:@var{n} pairs are treated
exactly as they are for T packets - they supply useful registers.
I'd have to add the expedited register support to any new reply packet
too, which would make it basically T without the signal number; this
version seems to complicate the protocol less.

> Should the protocol allow Key=Value pairs to appear in any order?  I
> don't think you really need to revise the reply template to show this,
> just a note to that effect would be plenty.

Yes indeed.

-- 
Daniel Jacobowitz
CodeSourcery