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.
>
> How likely is libvirt to need to introspect whether this extension is
> available? We've already argued that libvirt should already be giving
> everything an id, and therefore, the existing semantics of 'id' are
> already sufficient for libvirt's needs, and libvirt will never need to
> delete by qom-path, and thus does not need to introspect whether
> qom-path even works.
>
> Therefore, I'm leaning towards simplicity rather than introspection; and
> the patch is fine as-is from my viewpoint.
>
> --
> Eric Blake eblake redhat com +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
