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
>