8:48 a.m.
On Mon, May 09, 2016 at 09:30:30AM -0400, Cole Robinson wrote:
On 05/09/2016 07:30 AM, Pavel Hrdina wrote:
> On Sun, May 08, 2016 at 01:49:06PM -0400, Cole Robinson wrote:
>> Reports a tristate enum value for acceptable graphics type=spice
>> <gl enable=XXX/>.
>>
>> Wire it up for qemu too. 'no' is always a valid value, so we
>> unconditionally report it.
>> ---
>
> [...]
>
>> diff --git a/tests/domaincapsschemadata/domaincaps-full.xml
b/tests/domaincapsschemadata/domaincaps-full.xml
>> index 2f529ff..4eb5637 100644
>> --- a/tests/domaincapsschemadata/domaincaps-full.xml
>> +++ b/tests/domaincapsschemadata/domaincaps-full.xml
>> @@ -47,6 +47,11 @@
>> <value>desktop</value>
>> <value>spice</value>
>> </enum>
>> + <enum name='spiceGL'>
>> + <value>default</value>
>> + <value>yes</value>
>> + <value>no</value>
>> + </enum>
>
> Ewww, this doesn't look good and I agree with Michal that what if we add
> support for another graphics device and what if one graphics device will have
> more than one capability?
>
> I would suggest something like this:
>
> <graphics supported='yes'>
> <enum name='type'>
> <value>spice</value>
> <value>vnc</value>
> <value>sdl</value>
> </enum>
> <type name='spice'>
> <gl supported='yes'/>
> </type>
> </graphics>
>
> or even do something like this:
>
> <graphics supported='yes'>
> <type name='spice'>
> <gl supported='yes'/>
> </type>
> <type name='vnc'/>
> <type name='sdl'/>
> </graphics>
>
Really wish someone would have chimed in with this to my (unresponded) RFC
email about these things...
http://www.redhat.com/archives/libvir-list/2016-April/msg01839.html
That pattern is fine in this case, but what about the case of ports= element
that is only supported with a controller type=usb model=nec-xhci ? Do we have
new XML like:
<controller supported='yes'>
<type name='usb'>
<model name='nec-xhci'/>
<param name='ports' supported='yes'/>
</model>
</type>
</controller>
It seems like these types of relationships could grow deeply nested, so I
opted for following the limited existing convention of adding unique enum
names to represent the relationship.
Yeah, I find flat modelling quite desirable, because the relationships
between attributes will certainly grow quite complicate, and they do
not neccessarily form a nice simple tree relationship.
ie, whether foo=bar is permitted may depend on whether wizz=eek *AND*
when lala=ooh, and you can't have the enum for 'foo' nested underneath
the enum for 'wizz' & 'lala' at the same time. Also with nesting, if
you want the same values reported for multiple options, we end up
repeating the same information multiple times which is not good.
At the same time the flat modelling with "spiceGL" also doesn't scale
as you have to invent new names for each one, and again it doesn't
work if the 'gl' enum depended on type="spice" *and* something else
at the same time.
So I think we need a more flexible way to express dependancies here.
We could let the <enum> be repeated multiple times and express conditional
rules against each instance of the enum
So for example
<graphics supported='yes'>
<enum name='type'>
<value>spice</value>
<value>vnc</value>
<value>sdl</value>
</enum>
<enum name='gl'>
<condition>
<enum name="type" value="spice">
</condition>
<value>default</value>
<value>yes</value>
<value>no</value>
</enum>
<enum name='gl'>
<value>default</value>
<value>no</value>
</enum>
</graphics>
This would express that the first <enum type="gl"> entry only applies
when the @type == spice. If that doesn't match them fallback to the
second <enum type="gl">. The nice thing about this is that we can
make the conditions arbitrarly complex
For example:
<graphics supported='yes'>
<enum name='type'>
<value>spice</value>
<value>vnc</value>
<value>sdl</value>
</enum>
<enum name='gl'>
<condition op="and">
<enum name="type" value="spice">
<condition op="or">
<enum name="type" value="vnc">
<enum name="wibble" value="eek">
</condition>
</condition>
<value>default</value>
<value>yes</value>
<value>no</value>
</enum>
<enum name='gl'>
<value>default</value>
<value>no</value>
</enum>
</graphics>
This shows how the "gl" option can be used with VNC, but only if you
also have the @wibble attribute set to "eek".
Of course complex conditions like this become quite tedious & verbose
so obviously we should strive to keep them as simple as possible and
not use nested conditions unless absolutely needed.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|