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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list