SDP

[Maksim Yevmenkin]

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