Re: [Bluez-devel] hcid and bluetoothd

[Claudio Takahasi <cktakahasi@gmail.com>]

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

[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 playground for D-Bus
> > services. Probably, hcid D-Bus should be the starting point for
> > bluetoothd.
> 
> 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.
> 
> > 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.
> 
> 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. :)
> 
> 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 
periodic inquiry
I agree with this approach of send signals every time. We can implement a 
cache 
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 
integrated
in the main loop of the bluetoothd, using a HCI raw socket or the new 
interface that 
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
> 
> 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 
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-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)?
> 
> We can do both, but I think signals should be preferred. This allows
> graphical applications to dynamically update their lists.


[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 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.
> 
> We should keep an eye on security, but the idea is to send stuff to
> everybody that is interested in it.
> 
> > 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.
> 
> Once bluetoothd is 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 userspace
> > 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: 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: 7942 bytes --]