On 25.09.2012 14:47, Christophe Fergeau wrote:
On Tue, Sep 25, 2012 at 02:07:39PM +0200, Michal Privoznik wrote: Hey,
libvirt supports listen on IP address or a network and I think we need to distinguish these.
As I understand it, to listen on an IP address or a network, you'd use a <listen> child node to the <graphics> node. This patch sets the 'listen' attribute on the <graphics> node, which is only about listening on an IP address if I didn't miss anything (?).
No you didn't.
<listen> nodes would be handled in a separate class, but there could indeed be an ambiguity between a setter for an object of this type, and this API.
Yeah, this is what I had in mind. So if we ever add support for <listen> child elements we may wish _set_listen to be reserved just for this case: void gvir_config_domain_graphics_spice_set_listen(GVirConfigDomainGraphicsSpice *graphics, GList *listen); Same scenario is already happening for gvir_config_domain_set_devices().
s/gvir_config_domain_graphics_spice_set_listen/gvir_config_domain_graphics_spice_set_listen_ip/ maybe?
It seems it's not necessarily an IP address but this can be a hostname if the .rng is to be trusted. I had in the back of my mind the possibility of adding _set_listen_address which accepts a GInetAddress or something like that (just vague thoughts, I don't have a clear idea about that ;). So maybe _set_listen_str would work to avoid the ambiguity? Though as I write this mail, this looks weird too...
what about _listen_address(GVirConfigDomainGraphicsSpice *, const char *addr); with @addr being either IP or hostname (in fact anything that is acceptable for libvirt)?
Christophe