An agent that continuously runs (such as my script) is needed to handle INCOMING connections. After all, you never know, when a device will want to connect, so something has to be there and wait for pairing requests at all times.
For OUTGOING connections, you don't need a demon, because you know when you want to pair and/or make the connection. Thus, you only need to make a few dbus calls at a time that suits you and you're good.
Of course, outgoing connections have the complication that you need a gui to have the user select which device they want to connect to. Thus, the overall code for making outgoing connections may end up more complicated.
My script is about the simplest thing possible for incoming connections.
I didn't attempt to tackle outgoing connections at all because I don't need them (and I don't have a device to test with anyway). They should be mostly a gui building exercise with a few dbus calls.
Quote:(Btw, the same is true for my agent: if you want to switch the pairing mode of a running agent, there is no actual need to use the python script. You could make the dbus call from php directly.)
What I meant here is, that you could replace the "remote control" commands, the ones the don't pass the "--agent" option, by a dbus call from any other application, including a php script. In this case however, I don't see much of a benefit for re-implementing the dbus call and favouring it over calling the python script. (Quick note: this is a different dbus call. It's not one that goes to bluetoothd, but it's a dbus call between different instances of my script. The instance you're executing on the command line is telling the running instance (the agent) how to switch the pairing mode.)
This could be different if you decided to re-do the way outgoing connections are made.
For making outgoing connections, the benefit would be, that php can use the bluez api directly which might have benefits for looking up device names and properties and then pairing them. If you decide to write this part anew anyway, you might do it in php right away instead of writing a python script and then calling the python script from php and parsing its outputs. Again, this is for outgoing connections. For incoming ones, you need an agent that always runs.
In short: incoming and outgoing connections are conceptually very different in what you need to do, thus they require different solutions - even though they use the same dbus api.
