Date: Mon, 19 Jun 2006 21:25:05 +0100 (BST) From: Iain Hibbert <plunky@rya-online.net> To: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> Cc: freebsd-bluetooth@freebsd.org Subject: Re: SDP Message-ID: <1150748705.972874.2334.nullmailer@galant.ukfsn.org> In-Reply-To: <4496DCA8.2070405@savvis.net> 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> <44931C12.7020805@savvis.net> <1150571287.231614.2893.nullmailer@galant.ukfsn.org> <4496DCA8.2070405@savvis.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 19 Jun 2006, Maksim Yevmenkin wrote: [I chopped the order a bit] > it all boils down to what do we think libsdp(3) is. is it > > a) a generic library that only operates inside the sdp protocol scope, i.e. it > is only aware of sdp data elements and their types and *NOT* of the meaning of > these data elements to the end user application Yes, thats what I would like (I think we concur).. > b) a library that has complete awareness of all currently defined (in all > bluetooth profile documents) sdp attributes, their data types, format and > values and I dont like this type of system.. > obviously libsdp(3) can (and probably should) include more high-level > functions to parse "well-known" attributes and their values. and I think it would be nice if this was not necessary for ease of use. > after thinking about it, i'm somewhat confused by your statement "...telling > it what to look for...". ... > 2) from what i understand, libsdp(3) must know how to parse attribute given in > sdp_parse_t. in other words, libsdp(3) must know that > SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST is a sequence in a specific format, etc. i > think this means that if there is a new attribute and/or value format > libsdp(3) needs modification. No, my thought was to provide a fairly simple 'description' of the problem that you want solved. eg First, we tell the server, we are interested a particular service (eg DUN) and we get the PDU from the server. The PDU can be opaque for all we care, or it can be an array of attributes as is currently the case or flat as you suggested earlier. Thats not so important (I'm considering it opaque since as a client I dont want to parse it myself) So, if the description goes like this for ATTRIBUTE=PROTOCOL_DESCRIPTOR_LIST, we want to find UUID RFCOMM INT8 => <address> it scans the PDU and for each attribute looks at its list to see if it has anything for that attribute ID. When it has something, it scans the attribute chunk using the list we gave it - ie, in this case, for the PROTOCOL_DESCRIPTOR_LIST attribute it first wants to find a UUID matching RFCOMM before it can proceed, then it must find an INT8 value which it stores in the address given. When all the attributes are parsed, it returns and you just examine the addresses you gave it to see if contents have been updated. > right, please let me briefly describe what i had in mind for libsdp(3) > parsing. this would correspond to the item (a) from above. This is good and is necessary in any case, but my thought is that it still throws a lot of the parsing and interpretation onto the client program so I would like to take a step further. So far as I can see, it should be possible to parse the PDU without needing to know the complete structure as unknown portions can easily be skipped. The 'descriptor' language would obviously have to be a little more complex than as described above, but since any client would usually only want to parse a particular type of service then if it can be defined in a static structure manner that makes it easy to program and it should be clear to see what it is extracting from where. If it turns out that providing a bunch of macros to construct the descriptor 'program' dynamically is easier and neater then thats Ok too.. iain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1150748705.972874.2334.nullmailer>