Re: MI solib notification

[Vladimir Prus <vladimir@codesourcery.com>]

Eli Zaretskii wrote:

>> From: Vladimir Prus <vladimir@codesourcery.com>
>> Date: Tue, 17 Feb 2009 22:44:48 +0300
>> Cc: drow@false.org,
>>  gdb-patches@sources.redhat.com,
>>  nickrob@snap.net.nz
>> 
>> How about the attached, instead?
>> [...]
>> +@item =library-loaded,...
>> +Reports that a new library file was loaded by the program.  This
>> +notification has 4 fields---@var{id}, @var{target-name},
>> +@var{host-name}, and @var{symbols-loaded}. The @var{id} field is an
>> +opaque identifier of the library.  For remote debugging case,
>> +@var{target-name} and @var{host-name} fields give the name of the
>> +library file on the target, and on the host respectively. For native
>> +debugging, both those fields have the same value. The
>> +@var{symbols-loaded} field reports if the debug symbols for this
>> +library are loaded.
> 
> That's okay, but now I ask again why not do it like I suggested in the
> first place, viz.:
> 
>     @item =library-loaded,@var{info}
>     Reports that a new library file was loaded by the program.  @var{info}
>     includes 4 fields:
> 
>     @table @code
>     @item id="@var{id}"
>     Opaque identifier of the library.
>     @item target-name="@var{target-name}"
>     @itemx host-name="@var{host-name}"
>     For remote debugging case, @var{target-name} and @var{host-name}
>     fields give the name of the library file on the target, and on the
>     host respectively.  For native debugging, both those fields have the
>     same value.
>     ...
> 
> etc., you get the idea.  What you suggested now is very close to this,
> but I think my suggestion makes it easier to read and grasp.

I think the way you suggest is more complex. It introduces a new symbol 'info' 
that does not actually correspond to standalone entity in MI output and users
might begin to wonder what info actually is, and how it includes fields. Saying
that notification itself has 4 fields is more direct.

- Volodya