Re: [Bluez-devel] [PATCH] More SDP UUIDs...

Hi Fred,

quoted

quoted

I'm not sure if this question goes in the same direction, but what
happened to the idea of a general purpose rfcomm-inetd, which also sets
up sdp records for its clients? Maybe I'm not really up-to-date, and I
didn't find too much about it in the archives.. is there one already?

this makes no sense, because the SDP records are application (or call it
profile) specific. And the SDP infos should be coded in the application
itself and not in any master daemon.

I already have something like that working, but its a KDE daemon that runs 
under the user account of the current user. An application can specify a sdp 
record as an xml file, leaving the rfcomm channel attribute variable. The 
server looks for a free rfcomm port and sets up the sdp record for each 
application/registration file with the proper rfcomm channel. Of course this 
won't be flexible enough for some applications, but it makes life easier if 
you want a small daemon with a custom profile. Otherwise people are much more 
tempted to hardcode rfcomm channels for small applications.
I don't see why this shouldn't make any sense, but as long as there is no 
demand it's not worth the effort of course.

you don't got my point, because you are talking about two different
thinks. An inetd like daemon must know of the SDP records when it is
listening on the RFCOMM channels, because it must advertise them first
before another device can detect this service and make use of it. What
you are running is a wrapper for SDP record registration and RFCOMM
listen/accept commands.

Regards

Marcel




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel