Re: [Bluez-devel] DBus SDP API

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

On Thursday 23 November 2006 15:35, Marcel Holtmann wrote:
> Hi Denis,
>
> > Have you given any more thought as to how the RFCOMM channels are managed
> > by the DBus Service API?  The same goes for L2CAP.  From what I
> > understand the current implementation depends on clients to know what is
> > available...
>
> yes. That is where the "name" parameter in the XML record is for. You
> can simply override it with your own values. However this must be
> application or service specific.

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)

>
> > Will there be a lower-level SDP registration framework for the local
> > device? E.g. to be able to manually register records in binary/XML format
> > without creating a service agent?
>
> It is there at the moment by using the Bluetooth library. However I have
> no idea if it will stay there. I don't see any real use case except for
> debugging and with your enhancement to service-agent.c even that case is
> not really existent anymore.

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. 

>
> > Most importantly, do you have plans for local versions of
> >                 array{uint32} GetRemoteServiceHandles(string address,
> > string match)
> >
> > and
> >
> >                 array{byte} GetRemoteServiceRecord(string address, uint32
> > handle)
> >
> > ?
>
> I thought about that multiple times. Every time I convinced myself to
> implement it, I failed to find the use case for it.

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.

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

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