Hi guys,
we need to think about implementing the variable PIN helper support
within the D-Bus API. What is the best way to implement such kind of
communication?
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Johan,
> > Let me try expose some D-Bus features that can help us design the PIN
> > Agent better...
> >
> > Currently PinAgent uses the system bus connection. D-Bus is able to
> > start applications automatically. Applications with user interfaces
> > can't be started by system dbus-daemon, only the session can run this
> > kind of applications. Using the session bus connection, it is not
> > necessary has a applet/or a application always active. The D-Bus
> > starts the application when the first message is sent to the path.
> > For more information read the section "Message Bus Starting Services":
> > http://dbus.freedesktop.org/doc/dbus-specification.html
>
> I'm aware of the activation feature of D-BUS, and if you look through
> the bluez-devel archives you'll even find mails from me suggesting to
> use it a year ago or so. However, it's most likely not the right
> solution nor even feasible currently.
>
> The main problem is that we can't use the session bus for
> hcid/bluetoothd since the daemon is a system level service which doesn't
> know about any specific session (it might become possible in the future
> to discover existing session busses through the system bus, but
> currently this is not possible).
>
> Then there's the possibility of creating a bluetoothd specific interface
> for the user to tell it about the existence of his session bus. However,
> I have a feeling that this would over-complicate the D-BUS code, create
> all sorts of extra (e.g. security related) issues, and would conflict
> with the "discover session busses through system bus" feature which has
> been hinted as a possible addition to post-1.0 versions of dbus (you'll
> need to dig the dbus mailing list archives for the exact reference).
and who wants to decide to either start the KDE Bluetooth applet or the
Gnome Bluetooth applet. This isn't a decision that should be made by a
system service. As I said, let's keep the hcid/bluetoothd dumb.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Claudio,
On Tue, Feb 21, 2006, Claudio Takahasi wrote:
> Let me try expose some D-Bus features that can help us design the PIN
> Agent better...
>
> Currently PinAgent uses the system bus connection. D-Bus is able to
> start applications automatically. Applications with user interfaces
> can't be started by system dbus-daemon, only the session can run this
> kind of applications. Using the session bus connection, it is not
> necessary has a applet/or a application always active. The D-Bus
> starts the application when the first message is sent to the path.
> For more information read the section "Message Bus Starting Services":
> http://dbus.freedesktop.org/doc/dbus-specification.html
I'm aware of the activation feature of D-BUS, and if you look through
the bluez-devel archives you'll even find mails from me suggesting to
use it a year ago or so. However, it's most likely not the right
solution nor even feasible currently.
The main problem is that we can't use the session bus for
hcid/bluetoothd since the daemon is a system level service which doesn't
know about any specific session (it might become possible in the future
to discover existing session busses through the system bus, but
currently this is not possible).
Then there's the possibility of creating a bluetoothd specific interface
for the user to tell it about the existence of his session bus. However,
I have a feeling that this would over-complicate the D-BUS code, create
all sorts of extra (e.g. security related) issues, and would conflict
with the "discover session busses through system bus" feature which has
been hinted as a possible addition to post-1.0 versions of dbus (you'll
need to dig the dbus mailing list archives for the exact reference).
Johan
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Claudio,
> Let me try expose some D-Bus features that can help us design the PIN
> Agent better...
>
> Currently PinAgent uses the system bus connection. D-Bus is able to
> start applications automatically. Applications with user interfaces
> can't be started by system dbus-daemon, only the session can run this
> kind of applications. Using the session bus connection, it is not
> necessary has a applet/or a application always active. The D-Bus
> starts the application when the first message is sent to the path.
> For more information read the section "Message Bus Starting Services":
> http://dbus.freedesktop.org/doc/dbus-specification.html
I don't think that this is the right way to go. We will have a Bluetooth
applet running (like NetworkManager etc.) and this can handle the tasks
of PIN input. It only needs to tell hcid/bluetoothd that it exists and
where to call it.
If no PIN helper has been registered then the default action will be to
reject every PIN request. This is a clean approach and we can remove a
lot of code from hcid that tries to handle PIN input nicely. And if they
wanna have a fixed PIN then they need to write a PIN helper, but the
whole communication must go over D-Bus. And once version 1.0 of D-Bus is
out, I will make it mandatory for bluez-utils.
> > > > my current idea is to have a default handler that the applications have
> > > > to register over org.bluez.Manager and that they can have multiple other
> > > > PIN handlers registered via the org.bluez.Device interface for specific
> > > > devices. While the default handler is permanent, all other PIN handlers
> > > > may expire and get removed automatically.
> > >
> > > I think you'll still need a way to unregister the default handler, when
> > > e.g. a user logs out from his session (so the next user that logs in can
> > > register his own default handler).
>
> Remember that we can register fallback path(hierarchical path), where
> the root level can handle messages not handled by the child paths.
> Therefore, the default PIN Agent can be the base and the user defined
> can child paths.
I don't like this. The default action if no handler is registered must
be to reject the PIN request. Lets keep hcid/bluetoothd totally stupid.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Johan,
> > > Using org.bluez.Manager interface for registering the default handler
> > > seems to me extending too much its purpose compared to hald where we
> > > copied it from. The only purpose of the manager interface there is to
> > > allow local device discovery. Placing the default handler registration
> > > method at the interface org.bluez.Device (or org.bluez.Device.PinAgent)
> > > and object path /org/bluez/Device should be enough in my opinion. If you
> > > want to register a handler only for a specific local device then the
> > > exact path for that device (e.g. /org/bluez/Device/hci0) could be used.
> >
> > For the default handler the Manager interface makes perfect sense to me.
> > It has nothing to do with any device and it can be present even if no
> > Bluetooth device is attached at all. From me perspective we put every
> > non device specific things into the Manager interface. However I might
> > be missing something.
>
> Well, it depends how we define the purpose of the Manager interface :)
> If we say it's for "all stuff which is not device specific" then what you
> propose is ok. If we say it's only for local device discovery, as in
> hald, then the default handler registration shouldn't be in Manager.
>
> In my opinion non-device specific things could just use the root device
> path (/org/bluez/Device), while device specific stuff would use the
> exact device paths (e.g. /org/bluez/Device/hci0). But, I don't have any
> really strong opinion about this, so if you still insist on using
> Manager I wont complain anymore ;)
at the moment I don't have a strong opinion in any direction. I think we
need to choose something that looks sane from the client code.
> > > > Do we really only need the object path? I really like to get the default
> > > > handler thing implemented very soon.
> > >
> > > For the handler registration the object path should be enough. However
> > > we should probably rethink the org.bluez.PinAgent interface which
> > > currently consists of only one method: PinRequest.
> > >
> > > The PinRequest method currently takes two arguments: remote device
> > > address and a boolean indicating whether the connection is incomming or
> > > outgoing. A third parameter should probably be added for object path of
> > > the local device, since that information could be used for e.g. querying
> > > the name of the remote device.
> >
> > The interface must change. We use strings for the BD_ADDR now a clean
> > break is a good thing. Can you propose something?
>
> I'm not so convinced about the necessity of the "outgoing" boolean
> parameter, so depending on whether you want to keep it or not (we could
> add another device method for getting this information later) I'd
> propose one of the following:
> PinRequest(string bt_addr, string device_path)
> PinRequest(string bt_addr, string device_path, boolean outgoing)
>
> So a call could look like:
> PinRequest("11:22:33:44:55:66", "/org/bluez/Device/hci0")
the connection direction is not really helpful. Lets drop it for now.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi guys,
Let me try expose some D-Bus features that can help us design the PIN
Agent better...
Currently PinAgent uses the system bus connection. D-Bus is able to
start applications automatically. Applications with user interfaces
can't be started by system dbus-daemon, only the session can run this
kind of applications. Using the session bus connection, it is not
necessary has a applet/or a application always active. The D-Bus
starts the application when the first message is sent to the path.
For more information read the section "Message Bus Starting Services":
http://dbus.freedesktop.org/doc/dbus-specification.html
On 2/21/06, Marcel Holtmann <[email protected]> wrote:
> Hi Johan,
>
> > > my current idea is to have a default handler that the applications ha=
ve
> > > to register over org.bluez.Manager and that they can have multiple ot=
her
> > > PIN handlers registered via the org.bluez.Device interface for specif=
ic
> > > devices. While the default handler is permanent, all other PIN handle=
rs
> > > may expire and get removed automatically.
> >
> > I think you'll still need a way to unregister the default handler, when
> > e.g. a user logs out from his session (so the next user that logs in ca=
n
> > register his own default handler).
[Claudio Takahasi]
Remember that we can register fallback path(hierarchical path), where
the root level can handle messages not handled by the child paths.
Therefore, the default PIN Agent can be the base and the user defined
can child paths.
>
> I agree. In the first place I thought we can automatically unregister it
> when the program ends, but in case of desktop switching we need the
> Bluetooth applet playing nice.
>
> > Using org.bluez.Manager interface for registering the default handler
> > seems to me extending too much its purpose compared to hald where we
> > copied it from. The only purpose of the manager interface there is to
> > allow local device discovery. Placing the default handler registration
> > method at the interface org.bluez.Device (or org.bluez.Device.PinAgent)
> > and object path /org/bluez/Device should be enough in my opinion. If yo=
u
> > want to register a handler only for a specific local device then the
> > exact path for that device (e.g. /org/bluez/Device/hci0) could be used.
>
> For the default handler the Manager interface makes perfect sense to me.
> It has nothing to do with any device and it can be present even if no
> Bluetooth device is attached at all. From me perspective we put every
> non device specific things into the Manager interface. However I might
> be missing something.
>
> > > Do we really only need the object path? I really like to get the defa=
ult
> > > handler thing implemented very soon.
> >
> > For the handler registration the object path should be enough. However
> > we should probably rethink the org.bluez.PinAgent interface which
> > currently consists of only one method: PinRequest.
> >
> > The PinRequest method currently takes two arguments: remote device
> > address and a boolean indicating whether the connection is incomming or
> > outgoing. A third parameter should probably be added for object path of
> > the local device, since that information could be used for e.g. queryin=
g
> > the name of the remote device.
>
> The interface must change. We use strings for the BD_ADDR now a clean
> break is a good thing. Can you propose something?
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tue, Feb 21, 2006, Marcel Holtmann wrote:
> > Using org.bluez.Manager interface for registering the default handler
> > seems to me extending too much its purpose compared to hald where we
> > copied it from. The only purpose of the manager interface there is to
> > allow local device discovery. Placing the default handler registration
> > method at the interface org.bluez.Device (or org.bluez.Device.PinAgent)
> > and object path /org/bluez/Device should be enough in my opinion. If you
> > want to register a handler only for a specific local device then the
> > exact path for that device (e.g. /org/bluez/Device/hci0) could be used.
>
> For the default handler the Manager interface makes perfect sense to me.
> It has nothing to do with any device and it can be present even if no
> Bluetooth device is attached at all. From me perspective we put every
> non device specific things into the Manager interface. However I might
> be missing something.
Well, it depends how we define the purpose of the Manager interface :)
If we say it's for "all stuff which is not device specific" then what you
propose is ok. If we say it's only for local device discovery, as in
hald, then the default handler registration shouldn't be in Manager.
In my opinion non-device specific things could just use the root device
path (/org/bluez/Device), while device specific stuff would use the
exact device paths (e.g. /org/bluez/Device/hci0). But, I don't have any
really strong opinion about this, so if you still insist on using
Manager I wont complain anymore ;)
> > > Do we really only need the object path? I really like to get the default
> > > handler thing implemented very soon.
> >
> > For the handler registration the object path should be enough. However
> > we should probably rethink the org.bluez.PinAgent interface which
> > currently consists of only one method: PinRequest.
> >
> > The PinRequest method currently takes two arguments: remote device
> > address and a boolean indicating whether the connection is incomming or
> > outgoing. A third parameter should probably be added for object path of
> > the local device, since that information could be used for e.g. querying
> > the name of the remote device.
>
> The interface must change. We use strings for the BD_ADDR now a clean
> break is a good thing. Can you propose something?
I'm not so convinced about the necessity of the "outgoing" boolean
parameter, so depending on whether you want to keep it or not (we could
add another device method for getting this information later) I'd
propose one of the following:
PinRequest(string bt_addr, string device_path)
PinRequest(string bt_addr, string device_path, boolean outgoing)
So a call could look like:
PinRequest("11:22:33:44:55:66", "/org/bluez/Device/hci0")
Johan
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Johan,
> > my current idea is to have a default handler that the applications have
> > to register over org.bluez.Manager and that they can have multiple other
> > PIN handlers registered via the org.bluez.Device interface for specific
> > devices. While the default handler is permanent, all other PIN handlers
> > may expire and get removed automatically.
>
> I think you'll still need a way to unregister the default handler, when
> e.g. a user logs out from his session (so the next user that logs in can
> register his own default handler).
I agree. In the first place I thought we can automatically unregister it
when the program ends, but in case of desktop switching we need the
Bluetooth applet playing nice.
> Using org.bluez.Manager interface for registering the default handler
> seems to me extending too much its purpose compared to hald where we
> copied it from. The only purpose of the manager interface there is to
> allow local device discovery. Placing the default handler registration
> method at the interface org.bluez.Device (or org.bluez.Device.PinAgent)
> and object path /org/bluez/Device should be enough in my opinion. If you
> want to register a handler only for a specific local device then the
> exact path for that device (e.g. /org/bluez/Device/hci0) could be used.
For the default handler the Manager interface makes perfect sense to me.
It has nothing to do with any device and it can be present even if no
Bluetooth device is attached at all. From me perspective we put every
non device specific things into the Manager interface. However I might
be missing something.
> > Do we really only need the object path? I really like to get the default
> > handler thing implemented very soon.
>
> For the handler registration the object path should be enough. However
> we should probably rethink the org.bluez.PinAgent interface which
> currently consists of only one method: PinRequest.
>
> The PinRequest method currently takes two arguments: remote device
> address and a boolean indicating whether the connection is incomming or
> outgoing. A third parameter should probably be added for object path of
> the local device, since that information could be used for e.g. querying
> the name of the remote device.
The interface must change. We use strings for the BD_ADDR now a clean
break is a good thing. Can you propose something?
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
On Mon, Feb 20, 2006, Marcel Holtmann wrote:
> my current idea is to have a default handler that the applications have
> to register over org.bluez.Manager and that they can have multiple other
> PIN handlers registered via the org.bluez.Device interface for specific
> devices. While the default handler is permanent, all other PIN handlers
> may expire and get removed automatically.
I think you'll still need a way to unregister the default handler, when
e.g. a user logs out from his session (so the next user that logs in can
register his own default handler).
Using org.bluez.Manager interface for registering the default handler
seems to me extending too much its purpose compared to hald where we
copied it from. The only purpose of the manager interface there is to
allow local device discovery. Placing the default handler registration
method at the interface org.bluez.Device (or org.bluez.Device.PinAgent)
and object path /org/bluez/Device should be enough in my opinion. If you
want to register a handler only for a specific local device then the
exact path for that device (e.g. /org/bluez/Device/hci0) could be used.
> Do we really only need the object path? I really like to get the default
> handler thing implemented very soon.
For the handler registration the object path should be enough. However
we should probably rethink the org.bluez.PinAgent interface which
currently consists of only one method: PinRequest.
The PinRequest method currently takes two arguments: remote device
address and a boolean indicating whether the connection is incomming or
outgoing. A third parameter should probably be added for object path of
the local device, since that information could be used for e.g. querying
the name of the remote device.
Johan
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Johan,
> > we need to think about implementing the variable PIN helper support
> > within the D-Bus API. What is the best way to implement such kind of
> > communication?
>
> I'll first describe a couple of typical usage scenarios when this
> feature would be needed so others not involved in previous discussions
> know what we are talking about: Currently the D-BUS pin helper works so
> that when enabled hcid will call a PinRequest D-BUS method at a
> hardcoded service and object path (org.bluez.PinAgent and
> /org/bluez/PinAgent).
>
> This works fine as long as there is only need for one generic pin
> handler, e.g. a popup dialog. However, a piece of SW might want to
> implement e.g. a "pairing wizard" and take over handling of pin requests
> for a certain remote device for a short period of time. A SIM Access
> Profile implementation might also want to override the default handler
> with a GUI that automatically generates a 16 character PIN (which SIM
> Access Profile requires).
>
> A (somewhat simple) way to allow this kind of flexibility in PIN
> requests could be e.g. to have two methods for registering PIN handlers:
>
> 1. For registering the "default" handle you could have
> RegisterDefault(string object_path)
> This would tell hcid (or bluetoothd) that the "object" at the path
> object_path implements the org.bluez.PinAgent
> interface and is ready to handle PIN requests. I havent listed the
> service (or dbus name as it is called nowdays) in the arguments list
> since that information could be picked directly from the method call
> (using dbus_message_get_sender()). If we want to allow a service to
> register a handler on behalf of another service, then this extra
> parameter can of course be added.
>
> 2. For registering a "special" pin handler you could have e.g.
> RegisterSpecial(string object_path, string bt_addr)
> Same applies as for RegisterDefault, except that only PIN requests for
> the device identified by bt_addr would be delegated to this handler. A
> "unregister" method for this type of handler might not be necessary as
> we can have e.g. a timer for removing it automatically if nothing hapens
> for a while. The handler would naturally also be removed once pairing
> has succeeded with the device that the handler was registered for or if
> the service which registered the handler disappears from the bus.
my current idea is to have a default handler that the applications have
to register over org.bluez.Manager and that they can have multiple other
PIN handlers registered via the org.bluez.Device interface for specific
devices. While the default handler is permanent, all other PIN handlers
may expire and get removed automatically.
Do we really only need the object path? I really like to get the default
handler thing implemented very soon.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
On Mon, Feb 20, 2006, Marcel Holtmann wrote:
> we need to think about implementing the variable PIN helper support
> within the D-Bus API. What is the best way to implement such kind of
> communication?
I'll first describe a couple of typical usage scenarios when this
feature would be needed so others not involved in previous discussions
know what we are talking about: Currently the D-BUS pin helper works so
that when enabled hcid will call a PinRequest D-BUS method at a
hardcoded service and object path (org.bluez.PinAgent and
/org/bluez/PinAgent).
This works fine as long as there is only need for one generic pin
handler, e.g. a popup dialog. However, a piece of SW might want to
implement e.g. a "pairing wizard" and take over handling of pin requests
for a certain remote device for a short period of time. A SIM Access
Profile implementation might also want to override the default handler
with a GUI that automatically generates a 16 character PIN (which SIM
Access Profile requires).
A (somewhat simple) way to allow this kind of flexibility in PIN
requests could be e.g. to have two methods for registering PIN handlers:
1. For registering the "default" handle you could have
RegisterDefault(string object_path)
This would tell hcid (or bluetoothd) that the "object" at the path
object_path implements the org.bluez.PinAgent
interface and is ready to handle PIN requests. I havent listed the
service (or dbus name as it is called nowdays) in the arguments list
since that information could be picked directly from the method call
(using dbus_message_get_sender()). If we want to allow a service to
register a handler on behalf of another service, then this extra
parameter can of course be added.
2. For registering a "special" pin handler you could have e.g.
RegisterSpecial(string object_path, string bt_addr)
Same applies as for RegisterDefault, except that only PIN requests for
the device identified by bt_addr would be delegated to this handler. A
"unregister" method for this type of handler might not be necessary as
we can have e.g. a timer for removing it automatically if nothing hapens
for a while. The handler would naturally also be removed once pairing
has succeeded with the device that the handler was registered for or if
the service which registered the handler disappears from the bus.
So, if anyone has any thoughts about this feature, feel free to comment.
Johan
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel