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 <kkouk...@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-interfaces-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
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to