On Thu, Oct 4, 2012 at 4:15 PM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: > 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. Agreed. Thanks. Lucas De Marchi -- 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
