Re: [Bluez-devel] D-Bus patching session opened

[Marcel Holtmann <marcel@holtmann.org>]

Hi Claudio,

> I have some comments and questions:
>  
> 1. Multiple bluetooth adapters
> This is an old discussion but we didn't written it in a stone.
> Do you plan support address multiple local adapter or not?
> If yes, we have to plan how define the object path. My suggestion
> is insert the device id in the path(org/bluez/dev_id/hci, 
> org/bluez/dev_id/pan, ...).

my idea is that dev_id is only used inside the kernel and by bluetoothd
and that the D-Bus interface never exposes it. We should use device
names like "hci0" etc. or the device address. In generell the address in
unique and we should use it wherever possible, but with some tricks you
can have the same address attached to the same machine. However this
case is really not normal.

So I think we will use paths like org/bluez/hci0/ or with an address
like org/bluez/00:11:22:33:44:55/. For the default adapter we can use
the path org/bluez/default/.

> 2. Non D-Bus systems
> You wrote in an old email: "bluetoothd should combine hcid and sdpd".
> I didn't understand the scope of this assertion. IMHO in the future 
> for D-Bus enable systems bluetoothd should provide hcid, sdpd and 
> profiles services(D-Bus). 
> hcid features include control initialize/register) adapters and 
> provide D-Bus services for get adapter infos and basic task like 
> inquiry, scan, remote name, ..
> sdpd services include register/unregister local services, control
> incomming connections and D-Bus services for search services.
> Regarding sdp services, is it necessary provide a D-Bus service for
> register/unregister services or we have to use sdp_connect + 
> sdp_device_record_register?
> 
> As long as I could understand, bluetoothd will not be only a 
> D-Bus service provider, but it must support NON D-Bus clients too.
> Is that correct?

I thought that it would be a good idea to have an additional interface,
but I am not sure if that makes sense. Everything is going to use D-Bus
and so bluetoothd might only expose its interface over D-Bus. This will
make the development a lot easier.

> 3. API version
> We have to think how keep the backward compatibility among
> the future BlueZ D-Bus services versions. I my opinion we have three
> options:
>  - create a initialization service for bluetoothd where we 
>    can check the version.
>  - insert an extra arguments in each method call(request)
>  - define different interface name based on the API version

We can add a service to check the API version. That shouldn't be a big
problem.

> 4. Introspect
> It's becomming common implement a Introspectable interface that
> make possible get a xml string describing the provided services. 
> It can be a good feature support it.

>>From my point I try to avoid using XML wherever possible.

Regards

Marcel




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel