Hi Lucas, > >> >> Here is a rebased version of the patches. Most notable change is on patch > >> >> implementing the Set() method after feedback from Marcel. It doesn't cover the > >> >> concerns from Luiz about checking privileges per-property since I think this > >> >> could be added in a separate patch. As far as I could see the only user is > >> >> MediaTransport interface. The most obvious way would be to add another hook in > >> >> GDBusPropertyTable in order to check the privileges. Suggestions? > >> >> > >> >> First 2 patches could be applied nonetheles. Get and GetAll are well tested, > >> >> both now and in the previous version of this patch set. Set() is still a > >> >> bit raw - the users implementing it are very big (adapter, device) so > >> >> they are not converted yet (previous patch doesn't apply anymore and there's a > >> >> change in the API that requires them to be rewritten). > >> >> > >> >> > >> >> Lucas De Marchi (10): > >> >> gdbus: Move typedefs up > >> >> gdbus: Use macros to add annotations > >> >> gdbus: Add skeleton of DBus.Properties interface > >> >> gdbus: Implement DBus.Properties.Get method > >> >> gdbus: Implement DBus.Properties.GetAll method > >> >> gdbus: Implement DBus.Properties.Set method > >> >> gdbus: Add properties into Introspectable interface > >> >> gdbus: Implement PropertiesChanged signal > >> >> Use DBus.Properties on Control interface > >> >> Use DBus.Properties on Manager interface > >> >> > >> >> Luiz Augusto von Dentz (5): > >> >> gdbus: Add support for org.freedesktop.DBus.ObjectManager interface > >> >> gdbus: Group interface changes to reduce the amount of signals > >> >> emitted > >> >> gdbus: Only export ObjectManager interface on root path > >> >> gdbus: Integrates ObjectManager with Properties interface > >> >> gdbus: Simplify code for appending properties > >> >> > >> >> audio/control.c | 57 ++-- > >> >> gdbus/gdbus.h | 74 +++-- > >> >> gdbus/object.c | 867 +++++++++++++++++++++++++++++++++++++++++++++++++++----- > >> >> src/manager.c | 81 ++---- > >> >> 4 files changed, 897 insertions(+), 182 deletions(-) > >> > > >> > This initial set has been applied. Now let's get testing it and fix any > >> > pending issues that are found. Also please remember send the adapter and > >> > device conversions when you've got them ready so that we get them stress > >> > tested at the UPF next week. > >> > >> Thanks... I'll submit them soonish. > >> > >> Should we change the interface names to include a version, too? Or > >> change the bus name to something like bluez5? > > > > I am not in favor of that actually. Since this the reverse domain name. > > And we do not own bluez5.org and I am not planning to get a new domain > > name for every major release. > > > > We need to think about the versioning at some point, but maybe we leave > > that for BlueZ 6.x then. At some point we need to finish this one first. > > > Then if you are going to support both bluez4 and bluez5, there's no > way at runtime to determine which backend to use. > We already suffered from that with connman, for example. But it had > not hit 1.0 so we couldn't do much. > > Reverse domain name is just a convention, as is the major version > number. I'd prefer breaking the former convention rather than screwing > with the users or let them checking at compile time. > > For example, I have this on my desktop: > > org.freedesktop.PolicyKit1, > org.freedesktop.RealtimeKit1, > org.freedesktop.login1 > org.freedesktop.systemd1 > fi.w1.wpa_supplicant1 > > Do they all have these domains? yes, and the first 4 are subdomains. > Another option is to go with subdomains: org.bluez.v5 ;-) We could. Let the current code ObjectManager get stable first. It will get the first real exposure at the UPF next week. Then we see. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
