From owner-freebsd-bluetooth@FreeBSD.ORG Fri Jun 16 21:01:08 2006 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B817E16A479 for ; Fri, 16 Jun 2006 21:01:08 +0000 (UTC) (envelope-from maksim.yevmenkin@savvis.net) Received: from mailgate1b.savvis.net (mailgate1b.savvis.net [216.91.182.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F3D643D45 for ; Fri, 16 Jun 2006 21:01:08 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate1b.savvis.net (Postfix) with ESMTP id 67B1C3BEB4; Fri, 16 Jun 2006 16:01:07 -0500 (CDT) Received: from mailgate1b.savvis.net ([127.0.0.1]) by localhost (mailgate1b.savvis.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12990-02-11; Fri, 16 Jun 2006 16:01:07 -0500 (CDT) Received: from [10.254.186.111] (sntc04ep01.savvis.net [64.14.1.106]) by mailgate1b.savvis.net (Postfix) with ESMTP id E51813BE9A; Fri, 16 Jun 2006 16:01:06 -0500 (CDT) Message-ID: <44931C12.7020805@savvis.net> Date: Fri, 16 Jun 2006 14:01:06 -0700 From: Maksim Yevmenkin User-Agent: Thunderbird 1.5.0.2 (X11/20060603) MIME-Version: 1.0 To: Iain Hibbert 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> In-Reply-To: <1150486990.380039.25644.nullmailer@galant.ukfsn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at savvis.net Cc: freebsd-bluetooth@freebsd.org Subject: Re: SDP X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 21:01:08 -0000 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