Hi Marcel, >>>> I am not sure this is needed. What do you want to use it for? >> >> This is very useful to determine which device a service belongs to >> when an InterfacesAdded signal is sent for a service. We have an >> "Adapter" property for org.bluez.Device1, so why not a "Device" >> property for org.bluez.GattService1? > > the back reference should only be added if someone really uses them. > Well, we (the Chrome OS team) do, so that counts for something right (:P)? We used it in our implementation and Chaojie also seems to be interested in having this property so I think we should have it. > So this is problem that InterfacesAdded is only reporting for a single object path. Maybe this will actually work out as you described it. > Exactly. > Okay, then make the error really simple. Maybe even on a high-level like "not paired". Since the only action from the user here is really to start pairing with the device. > Sounds good to me. >> Yeah, I came up with these names pretty quickly while I was >> time-pressed for the Chrome 37 release. I don't have a strong opinion >> here; maybe EnableNotifications & DisableNotifications? Or maybe >> something that contains the word "session" since these methods behave >> like StartDiscovery and StopDiscovery on org.bluez.Adapter1. > > I leave it to others to comment here as well. It is an easy change in the end. > I'll leave it as it is for now, unless people object. >> I added this signal because I got rid of the property. Even if we keep >> the property, I'm still not convinced that using the PropertyChanged >> signal to mean both "cached value updated after read" and >> "notification/indication received" is the right idea. I sort of prefer >> having a signal that only gets called when there's a notification, >> though if we keep this property then I guess we're going to have to >> work with that. > > My thinking is that it really does not matter how the value got updated. Either by a manual read or by a notification or even by a write. The importance is to get the new value notified to all other applications that are not involved. Doing it only one way seems to make sense. And the applications all already have to listen to the PropertiesChanged signal anyway. Less signals to listen on the the better. > Ok, I guess this isn't so bad. >> To be honest, I don't think this property is that necessary. GATT/ATT >> don't really define a way to obtain these requirements in the >> characteristic declaration and leave them up to the upper layer >> profile and the only way to find out about these requirements is to >> issue a read/write request and see if there's an error. If we properly >> report errors to the client on calls to ReadValue and WriteValue, then >> this property wouldn't really be needed. Let me know if I'm missing >> something though. > > We might actually update it from the property does not exist to we have figured this out since someone read the property and thus we are reporting it now. I might be wrong, but I think there was some part in GATT that provided these details. Yeah, I guess this depends on how badly an application might need this property. We can just automatically update it after a read/write request. If we do want to keep it, then this property needs to be added to org.bluez.GattCharacteristic1 as well. I say we leave this property out for now and add it later if people feel that it's valuable to have it. -Arman -- 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
