From owner-freebsd-bluetooth@FreeBSD.ORG Thu Jun 15 18:03:22 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 03CC716A41A for ; Thu, 15 Jun 2006 18:03:22 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68B8343D45 for ; Thu, 15 Jun 2006 18:03:20 +0000 (GMT) (envelope-from plunky@rya-online.net) Received: from rya-online.net (du213-130-141-106.as15444.net [213.130.141.106]) by mail.ukfsn.org (Postfix) with SMTP id D1D6EE70A5; Thu, 15 Jun 2006 18:53:07 +0100 (BST) Received: (nullmailer pid 549 invoked by uid 1000); Wed, 14 Jun 2006 21:59:41 -0000 Date: Wed, 14 Jun 2006 22:59:41 +0100 (BST) To: Maksim Yevmenkin In-Reply-To: <44904A60.6080105@savvis.net> References: <1150200307.649295.228.nullmailer@galant.ukfsn.org> <44904A60.6080105@savvis.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1150322381.757072.1713.nullmailer@galant.ukfsn.org> From: Iain Hibbert 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: Thu, 15 Jun 2006 18:03:22 -0000 On Wed, 14 Jun 2006, Maksim Yevmenkin wrote: > when this comes up, i always refer people for openssl's err(3) Well, I looked at that and I'm not sure what the point of all that is.. seems very complex for what it is, but maybe some complexity is warranted when you have a threaded application. When I write code, my ideal would preferably be 'simplicity and elegance' and I think in this case, you went too far and it just got complicated for no great reason.. > there is, of course, little problem. because the errno values are reused, in > some cases, it is not possible to say if syscall has failed or something > inside library has failed. there does not (imo) need to be any such distinction in reality - the application program gets a notice of failure on a specific function (by a bad return code), and what the failure is. It doesnt matter where the error was. eg if sdp_open() returns ENOMEM then you know there was some memory failure. It is not important if it was sdp_open() that failed to allocate the handle structure, or if it was the kernel that failed to allocate the PCB. Of course, you as the library author are responsible to make sure that you dont have bugs that cause error returns with valid application arguments. > > specification is not clear at all. I thought of some way, possibly > > extending the attrlist that you used for sdp_search() to specify values > > that could be automatically extracted and leaving all the parsing inside > > the library. > > well, here is what i think. sdp(3) client knows *exactly* what it is looking > for. usually it is only required to get a few (less than 3) attributes to get > all the information. btw, I wonder why you made the attrlist take a range instead of an attribute? It leaves us with this kind of thing.. /* List of the attributes we are looking for */ static uint32_t attrs[] = { SDP_ATTR_RANGE( SDP_ATTR_SERVICE_RECORD_HANDLE, SDP_ATTR_SERVICE_RECORD_HANDLE), SDP_ATTR_RANGE( SDP_ATTR_SERVICE_CLASS_ID_LIST, SDP_ATTR_SERVICE_CLASS_ID_LIST), SDP_ATTR_RANGE( SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST, SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST), SDP_ATTR_RANGE( SDP_ATTR_BLUETOOTH_PROFILE_DESCRIPTOR_LIST, SDP_ATTR_BLUETOOTH_PROFILE_DESCRIPTOR_LIST) }; .. though I'm not sure how often how often a range of attributes could be desireable .. in fact, this could be cleared with another macro like: #define SDP_ATTR(attr) SDP_ATTR_RANGE(attr, attr) [later] actually, I'm guessing this is related to the spec somehow - looking at the BlueZ sdp_lib.h include file which seems to be the documentation, they look to use the same concept. > 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. I'm looking at the BlueZ include file now, they have a lot of functions I'm not exactly clear as to the use of, will have to see if I can find some example code to see if it looks any simpler in use. iain