>> "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.-- 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
