Linux bluetooth development
 help / color / mirror / Atom feed
From: Patrik Flykt <patrik.flykt@linux.intel.com>
To: linux-bluetooth@vger.kernel.org
Subject: Object manager properties on Network1 Connect method call reply
Date: Mon, 21 Jan 2013 10:30:02 +0200	[thread overview]
Message-ID: <1358757002.7854.27.camel@pflykt-mobl1> (raw)


	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



             reply	other threads:[~2013-01-21  8:30 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-21  8:30 Patrik Flykt [this message]
2013-01-21  9:25 ` Object manager properties on Network1 Connect method call reply Luiz Augusto von Dentz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1358757002.7854.27.camel@pflykt-mobl1 \
    --to=patrik.flykt@linux.intel.com \
    --cc=linux-bluetooth@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox