From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: From: Claudio Takahasi To: bluez-devel@lists.sourceforge.net Subject: Re: [Bluez-devel] D-Bus patching session opened In-Reply-To: <1127399305.5344.36.camel@blade> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9573_33340830.1127416413337" References: <1127399305.5344.36.camel@blade> Sender: bluez-devel-admin@lists.sourceforge.net Errors-To: bluez-devel-admin@lists.sourceforge.net Reply-To: bluez-devel@lists.sourceforge.net List-Unsubscribe: , List-Id: BlueZ development List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Sep 2005 16:13:33 -0300 ------=_Part_9573_33340830.1127416413337 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 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 ver= y > 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 > ------=_Part_9573_33340830.1127416413337 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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&qu= ot;.
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 rea= lly play
with the integration of D-Bus support into hcid and other daemo= ns. This
is the first step into creating a full D-Bus aware bluetoothd i= n the
future.

I like to see some more D-Bus enhancements now and Claud= io already
started and he's working hard in explaining his work and maki= ng me
happy. So please help him and review his code and send small patch= es 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?<= br>
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 whoare 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
h= elper written completely in Python.

There exists a job/task for ever= yone :)

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:=20 http://sourceforge.net/gero= nimo.php
_______________________________________________
Bluez-de= vel mailing list
Bl= uez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

------=_Part_9573_33340830.1127416413337-- ------------------------------------------------------- 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