Hi, On Sat, May 8, 2010 at 12:08 AM, Elvis Pfützenreuter <epx@xxxxxxxxxxx> wrote: >> >> Device objects exists for each paired device. If the pairing is >> removed the object is also removed and a new pairing is needed before >> connecting to it (as imposed by the whole bluetooth stack logic >> anyway). > > AFAIK the HDP source and sink must be paired before any session can be established, so the relevant device objects will always be there, so the path can be (re)used. Exactly, I tried to explain this before that device objects is a better way to expose any relevant API since that would be created anyway. It also has integration with the sdp record cache and are reloaded during the initialization and I hardly see us doing anything to revert this, since pretty much every plugin depend on this to work. So, with this in mind, IMHO, the whole concept of exposure the sessions won't fit nicely in BlueZ API, first because it uses the adapter path to create session passing a device path, which btw already is associated with adapter anyway, second because any client seems to be able to create those sessions even if they are unable to control them because they don't hold an agent, and third I don't think we should be exposing protocol internals in a D-Bus API, this id's make as much sense as the bdaddr in the ui (read _none_), it is as usable as we starting exposing local and remote seid (Stream Endpoint id, surprisingly similar to endpoint here) to pulseaudio to carry on with all avdtp protocol details, this will only fragment the logic around those bits and certainly won't make it work better. -- Luiz Augusto von Dentz Computer Engineer -- 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
