[libvirt] [dbus PATCH 1/8] Implement Capabilities property for connect Interface

[Katerina Koukiou]

On Mon, 2018-04-09 at 13:45 +0100, Daniel P. Berrangé wrote:
> On Mon, Apr 09, 2018 at 02:25:04PM +0200, Pavel Hrdina wrote:
> > On Mon, Apr 09, 2018 at 01:47:32PM +0200, Katerina Koukiou wrote:
> > > Signed-off-by: Katerina Koukiou <kkoukiou at redhat.com>
> > > ---
> > >  data/org.libvirt.Connect.xml |  4 ++++
> > >  src/connect.c                | 20 ++++++++++++++++++++
> > >  test/test_connect.py         |  1 +
> > >  3 files changed, 25 insertions(+)
> > 
> > Adding Dan to CC because I'm not that familiar with D-Bus
> > conventions.
> > This API can be exported as property, however it returns rather
> > large
> > string and not a simple value so I'm not sure whether method would
> > be
> > better in this case.
> 
> The concept of properties is essentially a convenience to make live
> easier
> for mapping into language bindings / higher level object systems.
> 
> At the protocol level, the properties are handling via a standard
> interface
> with a handful of methods
> 
> https://dbus.freedesktop.org/doc/dbus-specification.html#standard-int
> erfaces-properties
> 
> So whether you have a "Capabilities" property, or a "GetCapabilities"
> method, you'll still have a method call on the wire protocol, with
> the
> full string transmitted. There is also a signal that servers should
> emit when a property value changes so that clients know that if they
> have cached the property value, they should refetch it.
> 
> So potential issues are
> 
>  - If we don't emit PropertyChange signals, clients may cache out
>    of date capabilities
>  - If clients pre-fetch properties there'll be a small perf hit
>  - If we have lots of properties, then the overall size of all
>    properties combined might cause problems for GetAll
> 
> The first item is the one that would concern me in this instance.
> The libvirt capabilities data can change between calls, and libvirt
> has no way to notify you of such changes. Thus IMHO it is better
> exposed as a dynamic method call than a property.  Leave properties
> for libvirt things that are esentially static data, unless we're
> able to provide PropertyChange signals.
> 

Thanks for the detailed explanation. I will adjust it and repost.

> 
> 
> Regards,
> Daniel


Regards,
Katerina