[Bug 77189] [next] make TpBaseConnection GVariant-based

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=77189

--- Comment #7 from Xavier Claessens <xclaesse at gmail.com> ---
Overall, I think it is a good idea and I'm happy to see my commits can be
included into your plan :)

 - tp_dbus_connection_try_register_object() is starting to be really long and
pretty sequential. I would like to factor out at least 3 functions:
dup_skeletons_from_dbus_object(); dup_skeletons_from_svc_interfaces(); and
export_skeletons().

 - _register_object should check for GDBusObjectSkeleton instead of just
GDBusObject iface. You're not going to get GDBusInterfaceSkeletons out of a
GDBusObjectProxy. I would warn early if it's not a skeleton instead of
pretending everything is fine.

 - "TpSvcInterfaceSkeleton: move to the -dbus library" --> Hmm, that seems
pretty complex juggling with the properties mixin. I would move the whole
TpDBusPropertiesMixin to -core since ultimately we won't need it.

 - _tp_g_dbus_object_dup_interface_names(): I would take a varargs of
interfaces to ignore (or const gchar * const *ignore). Having just 2 is
arbitrary and "skip_type" is fine for a channel but TpBaseConnection abuse of
it for Requests.

 - "tp_base_connection_change_status: emit status-changed before
StatusChanged": Yes, and the update_rcc_property(self); should be moved earlier
as well for the same reason.

 - "tp_base_connection_set_self_handle: consolidate GObject setters": I don't
think it is needed, the gdbus-codegen emits PropertiesChanged in an idle
callback and aggregates changes. It's a bit complex with threading, though...
do you confirm the codegen is fine for our usage?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.