Return-Path: From: Denis KENZIOR To: BlueZ development Date: Thu, 23 Nov 2006 16:33:42 +1000 References: <200611231526.09459.denis.kenzior@trolltech.com> <200611231552.16972.denis.kenzior@trolltech.com> <1164261535.4847.19.camel@localhost> In-Reply-To: <1164261535.4847.19.camel@localhost> MIME-Version: 1.0 Message-Id: <200611231633.43210.denis.kenzior@trolltech.com> Subject: Re: [Bluez-devel] DBus SDP API Reply-To: BlueZ development List-Id: BlueZ development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Sender: bluez-devel-bounces@lists.sourceforge.net Errors-To: bluez-devel-bounces@lists.sourceforge.net 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