Re: HDP proposed api (ver 0.2)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux