Hi,
While implementing ConnMan Bluez 5 plugin using GDBusProxy from ./gdbus
I noticed the following things.
On org.bluez.Network1.Connect method call return the object properties
'Connected', 'Interface' and 'UUID' have not yet been updated. It is of
course obvious that if no error occurs, the network is connected. And
the interface is provided as an argument to the method call return
function so that's fine as well.
If the method call signals an error, then the network is of course not
connected. Except if the error is 'AlreadyConnected', which means it is.
Since it is not possible to send arguments in an error reply, the only
way to figure out the interface is via the 'Interface' GDBusProxy
property. 'Connected' and 'UUID' properties are also set properly in
this case.
>From the above it would be more consistent if the properties were
already set to their intended values when the Connect method call
returns independent of success or failure. Thus one set of logic would
suffice on ConnMan side to handle both cases.
Maybe the org.bluez.Network1 object properties could be updated only for
the Network1 object in question before sending the method call return?
Of course the devil may be in the details of the Bluez 5 API why the
object property update should not or can not be done this way.
Just my €0.02 on this.
Cheers,
Patrik
Hi Patrick,
On Mon, Jan 21, 2013 at 10:30 AM, Patrik Flykt
<[email protected]> wrote:
>
> Hi,
>
> While implementing ConnMan Bluez 5 plugin using GDBusProxy from ./gdbus
> I noticed the following things.
>
> On org.bluez.Network1.Connect method call return the object properties
> 'Connected', 'Interface' and 'UUID' have not yet been updated. It is of
> course obvious that if no error occurs, the network is connected. And
> the interface is provided as an argument to the method call return
> function so that's fine as well.
>
> If the method call signals an error, then the network is of course not
> connected. Except if the error is 'AlreadyConnected', which means it is.
> Since it is not possible to send arguments in an error reply, the only
> way to figure out the interface is via the 'Interface' GDBusProxy
> property. 'Connected' and 'UUID' properties are also set properly in
> this case.
I suppose you also have a callback to properties changed signal so in
case of AlreadyConnected error I guess you should not even call it if
you happen to detect it is already connected.
> From the above it would be more consistent if the properties were
> already set to their intended values when the Connect method call
> returns independent of success or failure. Thus one set of logic would
> suffice on ConnMan side to handle both cases.
>
> Maybe the org.bluez.Network1 object properties could be updated only for
> the Network1 object in question before sending the method call return?
> Of course the devil may be in the details of the Bluez 5 API why the
> object property update should not or can not be done this way.
Yep, we discussed this before an came to a conclusion that we probably
need a way to propagate changes immediately in certain situations to
avoid swallow changes, one idea was to modify
g_dbus_emit_property_changed to take a flag or create another property
flag e.g. G_DBUS_PROPERTY_FLAG_CHANGE_IMMEDIATELY or
G_DBUS_PROPERTY_FLAG_NO_WAIT.
--
Luiz Augusto von Dentz