Re: [Bluez-devel] bluetoothd D-Bus interface proposals(draft 00.05)

["Elvis Pfützenreuter" <elvis.pfutzenreuter@gmail.com>]

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

> Probably my poor english caused some misunderstanding, the address
> *IS* part of the object path already, I can handle several adapters
> without any problems right now, and every adapter has a path like
> /org/bluetool/<BDADDR>/device


Maybe even the "device" word in the path is unnecessary, since the address 
implies the notion of an adapter? Also, if you want to support multiple BT 
adapters, there could be a "default" path (independent of the address) so 
most applications would just use that instead of first finding the mac 
addresses of the adapters... How many machines in the world have more than 1 
adapter? :) 


if the property is not a string or the parameters are not bytes, an
> exception is thrown by the dbus wrapper (see the 'try' block at the
> beginning?) and I send an error message back to the caller explaining
> the error, otherwise everything goes on linearly
> 
> What the "database" does (this database is not sdpd, it's an object
> created by the bluetool daemon), is simply to find what "helpers" are
> installed (ie: reading a list from a configuration file) and execute
> them, not much more actually :) every helper in turn registers its own
> object path and waits


So, as I could understand, you would use one process per profile, and the 
main deamon would forward orders via DBUS to these 'slaves'?

Another thing, will all these deamons be integrated into bluez-utils? Or it 
would be an independent BT deamon initiative? Which would be the dependency 
relationship with bluez-utils, and other libraries like, possibly, glib?

A last comment (given that my DBUS knowledge is poor) would be that throwing 
all interfaces on the same object turns more difficult to the clients to 
identify which services are available (they would have to use some form of 
interface introspection (which is probably more boring than just scanning 
the object namespace?). Also, I don't know if it is possible to turn on/turn 
off some interface on an object at will during runtime - registering and 
unregistering an object I know it is quite easy :P
--
Elvis

[-- Attachment #2: Type: text/html, Size: 2556 bytes --]