From: Xavier Garreau <x.garreau@prim-time.fr>
To: "bluez-devel@lists.sourceforge.net" <bluez-devel@lists.sourceforge.net>
Subject: [Bluez-devel] sdp libs
Date: Tue, 30 Nov 2004 10:43:58 +0100 [thread overview]
Message-ID: <41AC40DE.8030706@prim-time.fr> (raw)
Hi,
Here's what I've got some more questions and remarks about sdplibs ...
First, i tried to use libuuid to parse a uuid encoded as a string but
uuid_t from libuuid and uuid_t from sdplibs conflict. Maybe sdp uuid_t
type should be renamed to sdp_uuid_t ?
If not, it could be great to add a function to sdp libs to parse an
128bits uuid string to a uuid_t or uint8_t* (i.e. adding arguments to an
drenaming the existing sdp_create_base_uuid, sdp_create_base_uuid could
then call this generic function).
I also would like to be sure to have understood the meaning of the
encapsulation of lists used for the protocol list attribute in sdp records.
We first have a list of choices for accessing the service
This list contains a list for each choice
This second level list contains a list for each protocol used for this
particular choice.
This third level list contains uuid of the protocol and parameters
related to the protocol.
For a service accesible both at RFCOMM and L2CAP levels (say on channel
3 if RFCOMM is used or PSM 4433 if L2CAP is used), we would have:
- List1 : Protocols list (1st level list)
- Choice 1 (2nd level List)
- Protocol 1 (3rd level List)
- L2cap UUID
- PSM used: 4433
- Choice 2 (2nd level List)
- Protocol 1 (3rd level List)
- Rfcomm UUID
- Channel used: 3
List1 is used as the second param to sdp_set_access_protos.
Is this right ?
I also noticed that the sdp api in libs2 seems to be easier to use ?
Thank you for commenting what need to be.
Regards,
--
Xavier Garreau
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
reply other threads:[~2004-11-30 9:43 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41AC40DE.8030706@prim-time.fr \
--to=x.garreau@prim-time.fr \
--cc=bluez-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox