Re: [Bluez-devel] DBus SDP API

[Denis KENZIOR <denis.kenzior@trolltech.com>]

On Thursday 23 November 2006 15:58, Marcel Holtmann wrote:
> > So hcid will never be responsible for allocating rfcomm channels?  I'm
> > not sure that's a good idea, since everybody will implement it themselves
> > (and probably get it wrong anyway)
>
> hcid can never be responsible for that, because that is the job of the
> kernel. However I am playing with the idea of an RFCOMM server in form
> of rfcommd in userspace that will allow simple RFCOMM based application
> and services.
>
> For the more complex ones you have to do it by yourself anyway. And you
> should make it open source anyway so we can tell you what went wrong ;)

Open sourcing it shouldn't be a problem.  Besides, our case is easy, we assume 
we _own_ the device ;)  

I'm more thinking of KDE/GNOME useage and meshing with command line daemons.  
I find it annoying that I have to know all the rfcomm channels, what they're 
used by etc, as is the case now.  If there was a framework for doing this 
intelligently, I think it would be of great benefit to everyone. The only 
place to put it seems to be hcid at this time.  

> > I see two advantages to doing this.  The main use case would be to
> > deprecate some aspects of sdptool and all the hairy code in there that
> > does the registration.  Move all of it to XML/Binary files.  The second
> > would be the completeness of the DBUS API.
>
> I am not buying the completeness argument. It is as simple as we don't
> have a SetAddress method.
>
> The hairy code in sdptool is only for development and extending the
> D-Bus API with development interfaces is not what I actually plan to do.
> It should stay as clean as possible and every method must actually have
> a user.

I understand, however such things are very useful to people who can't link to 
GPL'd libraries.  I seem to recall that DBus API was supposed to address such 
issues as well.  I'm not advocating throwing in everything and the kitchen 
sink, but I feel in this particular case it is useful.

> > Well I can see several useful things you can do:
> > - If hcid doesn't manage RFCOMM channels, how will an application know
> > dynamically what channel is available?  Such an operation will never be
> > atomic (another argument for doing it in hcid), but  at least you can do
> > selection semi-intelligently.
>
> You should write a full service for any kind of these use cases.

Are you advocating writing a hcid interface for this? E.g.

org.bluez.RfcommChannelAllocator or ...?

>
> > - I can see a GNOME / KDE app that displays all services running on the
> > local device, and use the UUIDs to identify exactly what type of service
> > it is (e.g. for icons) without having to rely on Text descriptions from
> > the DBus Service API.
>
> Then I would extend org.bluez.Service to return exactly that
> information, but the whole intention of the D-Bus based API is to hide
> as much Bluetooth specific things for the user interfaces as possible.

Hmm, this is a good idea by the way.  Perhaps the Service framework should 
extract the Service UUID and make it available when a record is provided?  
I'll try to look into this.

-Denis

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel