Date: Tue, 13 Jun 2006 13:05:07 +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: <1150200307.649295.228.nullmailer@galant.ukfsn.org>
next in thread | raw e-mail | index | archive | help
On Mon, 12 Jun 2006, Maksim Yevmenkin wrote: > > 1. sdp_open[_local]() may return a handle even though there is an error. > > well, its just the personal taste, imo :) personally, i do not like when > libraries (ab)use errno. while "errno-style" seems to be de-facto standard in > unix world, sometimes, (there is another world? :) > there is a need to have more sophisticated error > reporting. in my personal experience, sometimes, i cannot find an adequate > "errno" error to describe the nature of error. the existing sdp(3), imo, is a > middle ground. I thought there was some generic 'unknown error' errno but I dont see it now - I guess for something protocol specific then EPROTO could be used. Actually, I'm not so sure that <errno.h> is some kind of fixed standard, if an error exists that is not covered then there are still unallocated numbers.. I would say though, that setting errno is exactly what a library is supposed to do - it conveys extra information rather than 'failed' and its not really abusing it to set it when an operation fails.. so far as I can see, its not just for (eg) libc. > > 2. to register a profile with the sdp daemon, the daemon itself must > > already know about the profile, even though its just a string of binary. > > It would be nice if a client program could just prepare this array and > > send it. > > correct. the idea was to make sure that advertised sdp records are somewhat > consistent (and correct), and, to make life a little bit easier for clients. i > guess, we could add sdp_register_raw() what would simply use the data from the > client (after running some consistency checks). Yeah, I thought that was probably the case - my thought was that the daemon would at least validate the array before publishing it which at least covers 'consistent', and since registering a profile is privileged then the 'correct' is up to the sysadmin (or, whoever wrote the client) > > 3. parsing results of an sdp query is annoyingly ugly, it would be nice if > > there was some lib function that could be used to extract values from the > > result in a generic way. > > ahem... there *were* supposed to be helper functions, a-la > sdp_get_next_whatever() to simply advance pointers and copy data from them. i > just never got around to write them :( I might look at it again, just trying to finish something else now (and, my time has been limited for a few weeks) though I have to say, the SDP 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. > i took a brief look at this. it looks really good. i think we should start and > integrate our headers, i.e. make them the same and move them into some > reasonable please, say, /usr/include/bluetooth > > it certainly would be possible to get rid of NG_ prefix in freebsd include > files and do other tweaks as well. I chose /usr/include/netbt just to match with the other protocol family directories (and BTPROTO_ aswell) - not sure what FreeBSD does, I guess netgraph complicates things but actually, exact location is not so important because mostly I think <bluetooth.h> should be enough. I did think to move all the kernel stuff into xxxvar.h so that the files hci.h, l2cap.h, rfcomm.h etc would only contain the 'bluetooth' spec stuff though interdependencies get a bit confusing when you split the files up. I think, that it might go in as-is for now, as they are close to branching for 4.0 and it would be nice to be in for that, even if that means the API will change slightly later. regards, iain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1150200307.649295.228.nullmailer>