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