Re: [Bluez-devel] D-Bus interfaces

Marcel Holtmann
2004-02-09T00:38:06Z

Hi Fredrik,

> We can perhaps have alteranative interfaces for different purposes, if
> the difference in semantics is large enough. For example a "standard"
> HCI interface with all such methods. (I'm not familiar with HCI myself.)
>
> For example: org.bluez.hci
>
> For stuff that doesn't fit within HCI, or becomes very akward, we
> can have other complementary interfaces. GUI applications have other
> needs than for example server applications, I suspect. Having
> several interfaces for the same things isn't ideal though, but some
> overlap for the sake of the HCI standard is perhaps a good idea?
>
> > Lets talk about the namespaces you are thinking of. What makes sense to
> > separate?
>
> Some ideas:
>
> - Name services: including local device, paired and scanned
> names. Preferably using the same "lookup" function, because
> when searching for a name, applications don't want to bother
> where (local/remote/cache/whatever) the name comes from. Given
> a device address, simply return the name if it's readily
> available.
>
> Note that since initiating a scan is expensive, this ought
> to be a separate method call.
>
> Example: org.bluez.name
>
> - Key/pairing services: including requesting/receiving a pairing
> procedure, link key and PIN management.
>
> Example: org.bluez.link
>
> - (Local) device configuration services: activate/deactivate
> devices etc. Link modes? Classes? Or maybe org.bluez.hci will
> be enough for this?
>
> Example: org.bluez.device

not this way. I want to seperate the running services/profiles. The hcid
must serve "org.bluetooth.hci" as its base.

Regards

Marcel

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.