[Bluez-devel] D-Bus patching session opened

[Bluez-devel] D-Bus patching session opened

[Marcel Holtmann]

Hi,

after I dropped the D-Bus 0.23 API support it is now time to really play
with the integration of D-Bus support into hcid and other daemons. This
is the first step into creating a full D-Bus aware bluetoothd in the
future.

I like to see some more D-Bus enhancements now and Claudio already
started and he's working hard in explaining his work and making me
happy. So please help him and review his code and send small patches to
make the D-Bus experience better. I think about making the D-Bus a core
dependency of bluez-utils. Does anybody have any arguments against it?

Next thing that I like to see are some Python applications that are
using GTK+ and D-Bus for a graphical interface to BlueZ. For that I
think about creating a bluez-python package. Therefor we need people who
are writing the code and other people who are creating some nice fancy
icons and graphics for it. First thing should be a D-Bus aware PIN
helper written completely in Python.

There exists a job/task for everyone :)

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

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

[Claudio Takahasi]

[-- Attachment #1: Type: text/plain, Size: 3455 bytes --]

Hi Marcel,

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

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?

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

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.



Regards,
Claudio

On 9/22/05, Marcel Holtmann <marcel@holtmann.org> wrote:
>
> Hi,
>
> after I dropped the D-Bus 0.23 API support it is now time to really play
> with the integration of D-Bus support into hcid and other daemons. This
> is the first step into creating a full D-Bus aware bluetoothd in the
> future.
>
> I like to see some more D-Bus enhancements now and Claudio already
> started and he's working hard in explaining his work and making me
> happy. So please help him and review his code and send small patches to
> make the D-Bus experience better. I think about making the D-Bus a core
> dependency of bluez-utils. Does anybody have any arguments against it?
>
> Next thing that I like to see are some Python applications that are
> using GTK+ and D-Bus for a graphical interface to BlueZ. For that I
> think about creating a bluez-python package. Therefor we need people who
> are writing the code and other people who are creating some nice fancy
> icons and graphics for it. First thing should be a D-Bus aware PIN
> helper written completely in Python.
>
> There exists a job/task for everyone :)
>
> 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
>

[-- Attachment #2: Type: text/html, Size: 4181 bytes --]

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

[Marcel Holtmann]

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