Re: [Bluez-devel] DBus SDP API

[Marcel Holtmann <marcel@holtmann.org>]

Hi Denis,

> > > 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.  

actually you can ask the kernel to assign you the next free RFCOMM
channel if you really want to. That works perfectly fine and should be
enough for the complex applications.

If anyone mixes D-Bus and non D-Bus way of doing configuration and they
screw up, then I can't help them. We try to take everything possible
into account, but there are limits.

> > > 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.

They can write a service-agent.c example a like to register their SDP
record without putting the source code under GPL. Again, it is doable,
but going the closed source path is maybe more complex than the open
source way. I can live with that.

> > > 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 ...?

As mentioned above. The operation is atomic, because the kernel controls
it. You either can listen on that channel or not. What I meant was that
you have to write your own service for all kinds of things, but that is
the whole point in separating everything into small pieces.

> > > - 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.

We will do this internally at some point to better support extended
inquiry, but I still don't see any need for an application to know that
kind of information.

Regards

Marcel



-------------------------------------------------------------------------
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