Date: Wed, 14 Jun 2006 10:41:52 -0700 From: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> To: Iain Hibbert <plunky@rya-online.net> Cc: freebsd-bluetooth@freebsd.org Subject: Re: SDP Message-ID: <44904A60.6080105@savvis.net> In-Reply-To: <1150200307.649295.228.nullmailer@galant.ukfsn.org> References: <1150200307.649295.228.nullmailer@galant.ukfsn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Iain Hibbert wrote: > 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? :) ouch :) >> 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.. 'unknown error' is (imo) what modern strerror() implementations return on error code they do not understand, i.e. 0, -1 etc. it used to be that strerror() just crashed on such error codes. > 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. when this comes up, i always refer people for openssl's err(3) http://www.openssl.org/docs/crypto/err.html and specifically to http://www.openssl.org/docs/ssl/SSL_get_error.html# imo, this is both good and bad. good because one can know exactly what is going on, what failed and why. bad because api is not so easy do digest. first, one needs to look at openssl(3) error and then possibly at errno, etc. sdp(3), of course, is nowhere as complex as openssl(3). i tired to do a reasonable thing here. if syscall failed, sdp(3) will copy errno into session error. if something else went wrong, i.e. bad parameters, messages etc. sdp(3) tried to use appropriate errno value and put it into session error. 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. instead of implementing full scale error reporting, i simply left it as it is. should it be required to have more sophisticated error reporting in sdp(3) in would be easy to add it without breaking existing api (much). >>> 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) like i said, i have nothing against sdp_register_raw() or something like that. we both agree that the only thing sdpd(8) can verify is "well-formed"ness of the data. sdpd(8) cannot do a full check on the data if it does not know about the profile. >>> 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. 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. 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. i realize, that what i did/want for sdp(3) library is completely the opposite to what i did/want for sdpd(8) :) thanks, max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44904A60.6080105>