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