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

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(a)redhat.com&gt; > > --- > > 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.

Regards, Daniel