SDP
Maksim Yevmenkin
maksim.yevmenkin at savvis.net
Mon Jun 12 18:19:16 UTC 2006
Iain,
> in part of my work in Bluetooth for NetBSD* I just took the SDP
> implementation from FreeBSD direct to get a leg up and didnt look at it
> very much at first though I did make some changes, which basically
> comprised:
[...]
sounds good
> so what I have is still compatible at source level with FreeBSD. However,
> in adding the headset support I took a better look and I'm not sure I like
> the API exactly. I havent especially looked at the competing
> implementations, took a glance at the BlueZ one but they dont seem strong
> on documentation (and I didnt see any) and I'm hesitant to change the API
> as what we really dont need is yet another incompatible implementation.
>
> Some things I am uneasy with then:
>
> 1. sdp_open[_local]() may return a handle even though there is an error.
> Really, this is terrible! If there is an error in open, it should just
> return NULL and set errno accordingly. sdp_error() should not be
> necessary..
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 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.
> 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).
> 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 :(
> So well, I'm not so sure if anybody else besides Max has done any work in
> this arena, but any input is good..
your comments are very good. thanks a lot.
> *latest archive is http://homepages.rya-online.net/plunky/netbt.32.tar.gz
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.
thanks,
max
More information about the freebsd-bluetooth
mailing list