On Fri, May 7, 2010 at 10:46, Elvis Pfützenreuter <epx@xxxxxxxxxxx> wrote: >>> "Forcing" a source to specify the MDEP IDs here, even if not publishing the >>> record, makes checks easier further. >> >> Not sure about that. Note that when you don't publish a SDP record, nobody >> could connect to you, so you won't receive data channel connections request, >> so you don't need to check if the mdeps are in use or not. > > Indeed, you are right; from spec point of view I am not forced to define MDEP IDs beforehand (my old habits of TCP/IP, having ports both sides, sometimes overwhelm me :) > > The actual argument is higher level: whether should we *force* the application to specify the MDEP IDs / data types beforehand (as I "voted", with "my" API) or not (as you "voted"). > > This is the point we need more opinions, from people in the list :) > > >>> Perhaps you tried to accomodate the notion that a data channel ID >>> "survives" even if the device disappearrs for a short moment? >> >> Also this, remember that MCAP allow temporal disconnections to reestablish >> them in future connections to save state. > > Ok, I need to see whether BlueZ keeps the device objects in D-BUS tree after disconnection of if it removees it immediately. If it keeps the object, the sessions should be there as sub-paths (to be consistent with HdpSession being a part of adapter path.). If it doesn't, indeed they need to go somewhere else. 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). Re-using the device path and adding sessions as sub-paths seems reasonable, but I would wait on comments from Johan / Luiz / Marcel if this is desirable or might have any side-implication before defining this topic as closed. -- João Paulo Rechi Vita http://jprvita.wordpress.com/ -- 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
