Hi all, El Wednesday 12 May 2010 13:25:26 José Antonio Santos Cadenas escribió: > > > HDPAgent hierarchy > > > ================== > > > > > > > > > > > > (this object is implemented by the HDP client an receives > > > notifications) > > > > > > > > > > > > Service unique name > > > Interface org.bluez.HdpAgent > > > Object path freely definable > > > > > > > > > void DeviceConnected(object path) > > > > > > This method is called whenever a new device > > > > > > connection has been established over the control channel of the current > > > HDP session. The object path contains the object path of the remote > > > device. > > > > > > > > > void DeviceDisconnected(object path) > > > > > > This method is called when a remote device is > > > disconnected definitively. Any future > > > > > > reconnections will fail. Also all data channels associated to this > > > device will be closed. > > > > > > > > > void CreatedDataChannel(object path, uint16 mdlid) > > > > > > This method is called when a new data channel is > > > > > > created The path contains the object path of the device whith the new > > > connection is created and the mdlid the data channel identificator. > > > > > > > > > void DeletedDataChannel(object path, uint16 mdlid) > > > > > > This method is called when a data channel is > > > > > > closed. After this call the data channel will not be valid and can be > > > reused for future created data channels. > > > > > > > > Question from a user's perspective: why define an agent? Why not > > define the above as signal callbacks in the relevant object? (same as > > most APIs in "bluez/docs"). > > Because the this notifications are only relevant for the process that > created the session and this process should be the unique that receives > this events. If you define signals, everybody in the bus can be subscribed > to them, this is a problem in two ways: > - Noise in the bus > - "Privacy" issue because just the owner of the session should be > notified of the session events. > > > > > > > The only places I saw where agents are used are: BlueZ pairing (remote > > device object doesn't necessarily exist yet, so no way to register for > > its events, so an agent is required), and obexd (callback methods for > > authroization of transactions return a significant value, i.e. not a > > simple signal, so an agent is also required). > > > > > > > > But none of these conditions apply in the HDP agent above. So is there > > another reason? > > I explained above. > > If we are wrong and signals can be cached only by one process it is OK for > us to change this. > > > > > > > Also, why not add properties for > > connected/disconnected/opened/closed/etc. states? (And then > > "GetProperties()" method, and "PropertyChanged(name, value)" signal). > > For example, see "bluez/docs/network-api.txt"... > > Because this notifications concern to objects that are being created and > destroyed (in the case of devices) and created or closed data channels, so > new data channels ids are created or destroyed when this method are > called. I can't see how properties can help here. The channel may exist or > not I think that properties are not a good option in this case. > > Regards. Any comments about this issue. It will be great to receive a little bit more of feedback in order to decide one of this two options. -- 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
