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