Date: Wed, 14 Jun 2006 22:59:41 +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: <1150322381.757072.1713.nullmailer@galant.ukfsn.org> In-Reply-To: <44904A60.6080105@savvis.net> References: <1150200307.649295.228.nullmailer@galant.ukfsn.org> <44904A60.6080105@savvis.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1150322381.757072.1713.nullmailer>