Am 01.09.2015 um 17:58 schrieb Programmingkid:
> On Sep 1, 2015, at 11:55 AM, Eric Blake wrote:
>> On 09/01/2015 07:23 AM, Daniel P. Berrange wrote:
>>>>> +Remove device @var{id}. @var{id} may be a short ID
>>>>> +or a QOM object path.
>>>>
>>>> Have you considered using two alternative parameters, id and qom-path?
>>>> (qom_path was used elsewhere)
>>>
>>> I'm not fussed either way, but I thought it simpler to not try to change
>>> the accepted parameters of the existing commands. Looking, the only
>>> place I notice that uses a 'qom_path' is the return data in the CpuInfo
>>> struct.
>>>
>>> Does anyone have strong feelings either way about use of id for both vs
>>> qom-path or id ?
>>
>> Reusing 'id':
>> - Pros
>> - less complicated interface (don't have to check for mutual exclusion)
>> - Cons
>> - not introspectible (can't tell by introspection alone whether id can
>> take a QOM path)
>> - confusing name (but not the first time we've had that issue)
>>
>> Adding 'qom-path':
>> - Pros
>> - introspectible
>> - JSON expresses everything (we don't have to parse the first
>> character of the string to know which style was meant, as the choice of
>> key already decided it)
>> - Cons
>> - Have to implement mutual exclusion ourselves (can't take 'id' and
>> 'qom-path' at the same time, and at least one must be specified), unless
>> we invent a new way for qapi to express mutual exclusion (there are
>> other existing commands that would benefit from such an extension)
>
> Don't forget having a really long command to type up just to find out
> what qom path you need.
>
> Also the qom path itself is very long. A simple ID is much easier to type out.
That's besides the point: IDs can already be specified without this
patch. This patch is shoehorning QOM paths into an existing ID argument.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)
