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