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] hcid and bluetoothd In-Reply-To: <1126775298.28510.40.camel@station6.example.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8855_14909712.1126793077956" References: <1126775298.28510.40.camel@station6.example.com> 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, 15 Sep 2005 11:04:37 -0300 ------=_Part_8855_14909712.1126793077956 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline [Claudio Takahasi] Hi Marcel, On 9/15/05, Marcel Holtmann wrote: >=20 > Hi Claudio, >=20 > > You said in an old e-mail that hcid is your playground for D-Bus > > services. Probably, hcid D-Bus should be the starting point for > > bluetoothd. >=20 > since it is there and used, I think it is a good idea. At the moment it > is optional and so we can test it. At some point I will make bluez-utils > depend on D-Bus. >=20 > > I would like to align your ideas to avoid future reworks. > > > > D-Bus provides 4 types of messages: > > 1. Method call > > 2. Method reply > > 3. Signals > > 4. Error > > Currently, only signals are sent. The following signals are sent as > > result of the hci commands: > > - InquiryStart > > - InquiryResult > > - InquiryComplete > > - RemoteName > > path: /org/bluez/DevAgent > > interface: org.bluez.DevAgent > > > > The topics that I want discuss are: > > 1. hcid signals > > In my opinion it is not necessary send signals to notity inquiry > > start/complete. Only signals for news devices are enough. >=20 > The idea behind also sending the InquiryStart and InquiryComplete events > is that applications can show some graphical indications that the local > device is now scanning for new devices in range. Since people can still > call "hcitool scan" it is need for applications to know when someone > else starts an inquiry. > Another aspect is, inquiry result can contain repeated devices. This > > approach could cause D-Bus app client overhead(inconsistency), by > > other hand if periodic inquiry is active repeated signals must be sent > > because more than one client can be filtering these signals and they > > can start at different time. :) >=20 > And the RSSI values may changes in the repeated reponses. The clients > must do the filtering. There is no other way. [Claudio Takahasi] Remember that we need cover normal inquiry and periodic inquiry. For=20 periodic inquiry I agree with this approach of send signals every time. We can implement a= =20 cache=20 to make the inquiry fast/powerful. Two or more clients can request inquiry= =20 at same=20 time, this is a normal scenario, but it can happen. For normal inquiry, we= =20 can't use hci_inquiry because it a blocking operation. The inquiry must be=20 integrated in the main loop of the bluetoothd, using a HCI raw socket or the new=20 interface that=20 your are defining. > 2. hcid and bluetoothd object path > > What is the object path that you want use? > > I suggested in an old email use a hierarchical paths. bluetoothd can > > be the main object path provided at /org/bluez/bluetoothd, hci D-Bus > > services could be provided at /org/bluez/bluetoothd/hci >=20 > The general idea is to abstract from any daemon names or Bluetooth > specification details. This makes it possible to reuse this interface > with FreeBSD in the future. [Claudio Takahasi] I suggested previously use the bus name "org.bluez.bluetoothd", but do you= =20 think=20 relevant participate on freedesktop project? The bus name could be "org.freedesktop.Bluez" I don't know what are the advantages and which rules we need respect. > 3. D-Bus services > > hci D-BUS services is the next step, I am going to starting coding > > ASAP. Regarding inquiry requests, what kind of implementation do you > > prefer, send method reply message or send only signals(like the > > current)? >=20 > We can do both, but I think signals should be preferred. This allows > graphical applications to dynamically update their lists. [Claudio Takahasi]=20 I agree. We need define exactly which signals are necessary. I am going=20 to update the specification document that I am writing and I will send you= =20 soon. > If you use signals, all D-Bus client capturing D-Bus hci signals are > > able to see the new devices found. Using a method reply only the peer > > (requestor) will receive. Using a method reply approach, we can > > implement device class filters and avoid repeated devices. We have the > > same problem for remote name, disconnect, authentication/security, > > info, role switch and display connections. >=20 > We should keep an eye on security, but the idea is to send stuff to > everybody that is interested in it. >=20 > > 4. bluetoothd > > There are shared codes like(pand/bnep.c, pand/sdp.c, hidd/sdp.c, ...) > > that we need be aware. > > It is NOT clear for me how hcid and bluetoothd should work. hcid must > > be running all the time, but the hci D-Bus service will be running > > only if the system has a D-Bus system daemon running. Therefore, who > > should register the hci object path? IMHO, bluetoothd should > > centralize all D-Bus services. It will not be easy separate the > > "normal" code from the "D-Bus code". Maybe your "new interface" that > > your are defining can solve this problem. >=20 > Once bluetoothd is in place hcid would no longer be needed. [Claudio Takahasi]=20 hcid already contains the structure(main loop) required to register=20 D-Bus services, it will be easy implement the D-Bus services. Regarding sdpd, currently an application have to connect(sdp_connect)=20 and stablish a session to register/update a service.=20 sdp D-Bus service shall be provided in the future, how do you=20 think it should work in this new scenario? > 5. new interface > > You said that a new interface for kernel and the userspace > > communication is being defined. What is the current status? >=20 > I am working on it. [Claudio Takahasi]=20 Where is the CVS branch? If possible, send me the address. Regards >=20 > Marcel >=20 >=20 >=20 >=20 > ------------------------------------------------------- > 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_8855_14909712.1126793077956 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline [Claudio Takahasi]
Hi Marcel,

On 9/15/05, Marcel Holtmann <marcel@holtmann.org> wrote:
Hi Claudio,

> You said in an old e-mail that hcid is your playgro= und for D-Bus
> services. Probably, hcid D-Bus should be the starting= point for
> bluetoothd.

since it is there and used, I think i= t is a good idea. At the moment it
is optional and so we can test it. At some point I will make bluez-util= s
depend on D-Bus.

> I would like to align your ideas to avoid= future reworks.
>
> D-Bus provides 4 types of messages:
> 1. Method call
> 2. Method reply
> 3. Signals
> 4. E= rror
> Currently, only signals are sent. The following signals are se= nt as
> result of the hci commands:
> - InquiryStart
> - = InquiryResult
> - InquiryComplete
> - RemoteName
> path: /org/bluez/De= vAgent
> interface: org.bluez.DevAgent
>
> The topics tha= t I want discuss are:
> 1. hcid signals
> In my opinion it is n= ot necessary send signals to notity inquiry
> start/complete. Only signals for news devices are enough.

T= he idea behind also sending the InquiryStart and InquiryComplete events
= is that applications can show some graphical indications that the local
device is now scanning for new devices in range. Since people can still=
call "hcitool scan" it is need for applications to know when = someone
else starts an inquiry.
> Another aspect is, inqu= iry result can contain repeated devices. This
> approach cou= ld cause D-Bus app client overhead(inconsistency), by
> other hand if= periodic inquiry is active repeated signals must be sent
> because more than one client can be filtering these signals and th= ey
> can start at different time. :)

And the RSSI values may c= hanges in the repeated reponses. The clients
must do the filtering. Ther= e is no other way.

[Claudio Takahasi]
Remember that we need cover  normal inquiry and periodic inquiry. For = periodic inquiry
I agree with this approach of send signals every time. We can implement a c= ache
to make the inquiry fast/powerful. Two or more clients can request inquiry = at same
time, this is a normal scenario, but it can happen. For normal inquiry, we = can't
use hci_inquiry because it a blocking operation. The inquiry must be integr= ated
in the main loop of the bluetoothd, using a HCI raw socket or the new inter= face that
your are defining.
 

&= gt; 2. hcid and bluetoothd object path
> What is the object path that= you want use?
> I suggested in an old email use a hierarchical paths. bluetoothd c= an
> be the main object path provided at /org/bluez/bluetoothd, hci D= -Bus
> services could be provided at /org/bluez/bluetoothd/hci

The general idea is to abstract from any daemon names or Bluetooth
s= pecification details. This makes it possible to reuse this interface
wit= h FreeBSD in the future.
[Claudio Takahasi]
I suggested  previously use the bus name "org.bluez.bluetoothd&qu= ot;, but  do you think
relevant participate on freedesktop project?

The bus name could be "org.freedesktop.Bluez"

I don't know what are the advantages and which rules we need respect.
 
> 3. D-B= us services
> hci D-BUS services is the next step, I am going to star= ting coding
> ASAP. Regarding inquiry requests, what kind of implementation do y= ou
> prefer, send method reply message or send only signals(like the<= br>> current)?

We can do both, but I think signals should be pref= erred. This allows
graphical applications to dynamically update their lists.
<= div>
[Claudio Takahasi] 
I agree. We need define exactly which signals= are necessary. I am going
to update the specification document that I am writing and I will send you = soon.

> If you u= se signals, all D-Bus client capturing D-Bus hci signals are
> able t= o see the new devices found. Using a method reply only the peer
> (requestor) will receive. Using a method reply approach, we can> implement device class filters and avoid repeated devices. We have th= e
> same problem for remote name, disconnect, authentication/security= ,
> info, role switch and display connections.

We should keep a= n eye on security, but the idea is to send stuff to
everybody that is in= terested in it.

> 4. bluetoothd
> There are shared codes li= ke(pand/bnep.c, pand/sdp.c, hidd/sdp.c, ...)
> that we need be aware.
> It is NOT clear for me how hcid and= bluetoothd should work. hcid must
> be running all the time, but the= hci D-Bus service will be running
> only if the system has a D-Bus s= ystem daemon running. Therefore, who
> should register the hci object path? IMHO, bluetoothd should
&g= t; centralize all D-Bus services. It will not be easy separate the
> = "normal" code from the "D-Bus code". Maybe your "n= ew interface" that
> your are defining can solve this problem.

Once bluetoothd i= s in place hcid would no longer be needed.

[Claudio Takahasi]
hcid already contains the structure(main loop) required to register
D-Bus services, it will be easy implement the D-Bus services.

Regarding sdpd, currently an  application have to connect(sdp_connect)=
and stablish a session to register/update a service.
sdp D-Bus service shall  be provided in the future, how do you
think it should work in this new scenario?

> 5. new= interface
> You said that a new interface for kernel and the userspa= ce
> communication is being defined. What is the current status?
I am working on it.

[Claudio Takahasi]
Where is the CVS branch? If possible, send me the address.

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_8855_14909712.1126793077956-- ------------------------------------------------------- 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