Re: PPTP Plugin Updated -- Ver. 0.6.9 Generally PPP capable?

[Matthew Garrett <mjg59 srcf ucam org>]

On Wed, Jun 07, 2006 at 09:37:48AM +0200, Marcel Holtmann wrote:

> we will have a full D-Bus API for most common tasks in the next BlueZ
> release. It will be bluez-utils-3.0 and we are just working on the last
> few blocker bugs. My actual plan is to get it out this week.

Yup. I've been working on this with CVS.

> The API includes support for device discovery, pairing functions and a
> couple of signals for stuff that might happen behind your back. So in
> most cases there is no longer need to query stuff. However it doesn't
> support service discovery at the moment. We need to rewrite the SDP
> layer to make it fully asynchronous and there was simply no time for it,
> but this will be addressed in future versions.

I planned on mirroring bluetooth information in hal, rather than leaving 
it up to applications to query bluez directly. There's two reasons for 
this:

1) It makes it easier for applications if there's one source of 
information about hardware they can drive. Networkmanager, for instance, 
will want to know about bluetooth devices, ir devices, any 
serially-connected modems we can probe, usb modems (where supportable) 
and so on.

2) For certain trivial purposes, it means that the application doesn't 
need to rely on the bluez API - any different bluetooth stack can just 
be hidden behind hal.

> To make Bluetooth fully HAL aware you need to include SDP into the
> kernel and you don't wanna to that. Trust me. The protocol is so bad and
> the number of remote exploits would increase, because you simply can't
> get the implementation right.

Though hal generally pulls stuff out of sysfs, there's no reason that it 
has to. The current interface that I'm playing with is something like 
the following:

Bluetooth HCI controllers will provide a "Scan" method. Calling 
org.freedesktop.Hal.Device.Bluetooth.Scan on that controller will then 
populate the hal tree with any discovered devices and their names (where 
available). Each of these devices will support two further methods - 
"Browse" and "Pair". Pair is fairly obvious, and Browse will make sdp 
calls to further populate the hal tree with individual services (it 
makes sense to think of these as individual devices from the hal point 
of view). So, we might end up with something like this:

pci
  usb controller
      bluetooth controller
          phone
             obex ftp
             dial up networking

with appropriate capabilities flags.

None of this is strictly dependent upon bluez providing a dbus 
interface, though that makes life a great deal easier than having to 
do things the old way.

> One of my ideas is to have an enhanced pand with D-Bus support that will
> take care of PAN and LAN access connections. So NetworkManager can use
> this daemon to establish Bluetooth connections.

That would also be cool.
-- 
Matthew Garrett | mjg59 srcf ucam org