Date: Fri, 16 Jun 2006 14:01:06 -0700 From: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> To: Iain Hibbert <plunky@rya-online.net> Cc: freebsd-bluetooth@freebsd.org Subject: Re: SDP Message-ID: <44931C12.7020805@savvis.net> In-Reply-To: <1150486990.380039.25644.nullmailer@galant.ukfsn.org> References: <1150200307.649295.228.nullmailer@galant.ukfsn.org> <44904A60.6080105@savvis.net> <1150322381.757072.1713.nullmailer@galant.ukfsn.org> <4492E9FA.2030708@savvis.net> <1150486990.380039.25644.nullmailer@galant.ukfsn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Iain, >>>> sdp(3) client knows *exactly* what the format of the >>>> attributes should be. so, sdp(3) library should provide simple api to >>>> locate >>>> given element of given type in raw data and extract data from it. imo, >>>> more >>>> intelligent parsing could require sdp(3) to actually know about the >>>> profile >>>> client is trying use. >>> Yes was thinking along those lines.. the client would provide a structure >>> detailing how to parse the required attributes where to put the values. >> may be. so far i have not seen a need for that. > > I looked at the BlueZ implementation and for the sdp query function, they > parse the flat results and return a linked list then have a bunch of extra > functions that extract specific values. See attached file for example in > use to find SPP (ie RFCOMM channel) > > It does look neater, but I'm not sure I like the exact concept. sigh... i've seen the bluez sdp code. in fact, i try to keep track of what bluez folks do. it seems like (to me) that current bluez sdp api is, in some form, re-incarnation of the very first original sdpd and sdptool code. i'm not sure why bluez folks so keen on linked list concept for sdp data. here is what i mean: when sdp transaction is complete the client has all the attributes and all attribute values packed into the pdu in "sdp wire" format. it is a perfectly acceptable format to parse. in fact, it is a great format, because it is possible to parse it (and extract the values) in-place without allocating any memory or modifying original data. i'm not sure why is it required to parse all the data and re-pack it into the linked list, just to have another api that would search and extract data from the linked list. i admit that linked list is an easy to understand concept for a human, but for a machine it does not make any difference at all. i had a chance to work with csr bluelab sdk recently and develop the application that actually runs on the csr chip inside the virtual machine and does not require any host stack. this is very resource limited environment. when i looked at what csr sdk api is for sdp, i realized that is somewhat similar to what i've suggested/done in libsdp(3). the idea is the same, get the raw bytes from the remote device and use simple functions that parse it in-place and locate elements of given type to extract their values. in fact, splitting attributes and putting them into separate buffers was probably a bad idea in libsdp(3). i should have just return the whole pdu (minus header) to the client and have it deal with it. like i said, libsdp(3) misses utility functions to parse/extract values, but they are easy to write. by simply passing/using pointers within original buffer one can make these utility functions thread-safe, reentrant and recurse-friendly without any trouble at all. in fact, those functions do not even need a sdp_session object, just a buffer and few pointers. thanks, max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44931C12.7020805>