Linux bluetooth development
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH BlueZ 3/6] gdbus: Introduce GDBusInterfaceFlags
Date: Sun, 23 Dec 2012 08:30:39 -0800	[thread overview]
Message-ID: <1356280239.29264.28.camel@aeonflux> (raw)
In-Reply-To: <CABBYNZ+set-vvzf+6whfPt5zE8c7X_t2DB4vJS6p8v2X0i_U-A@mail.gmail.com>

Hi Luiz,

> >> The flags should be passed in g_dbus_register_interface_with_flags,
> >> currently there only one flag which is G_DBUS_INTERFACE_FLAG_EXPERIMENTAL
> >> which works similarly to G_DBUS_METHOD_FLAG_EXPERIMENTAL but for the
> >> whole interface.
> >> ---
> >>  gdbus/gdbus.h  | 13 +++++++++++++
> >>  gdbus/object.c | 20 ++++++++++++++++++++
> >>  2 files changed, 33 insertions(+)
> >
> > can we not just check if the interface contains any non experimental
> > method, signals and properties and base that decision around that?
> 
> It can work, but we would have to iterate on every single item, so in
> terms of code is quite a bit more complex so I favored adding a new
> function even though we might replace it in the long run.

we have to iterate over every single item in the success case anyway, so
why bother trying to optimize this.

> > I am not really in favor of introducing a version with flags.
> 
> The final solution I was thinking is passing another interface
> containing the table as this tend to be quite static e.g.:

If this is not the final solution you are heading for, then lets not
even bother introducing it. Lets go with the the simple approach that
does not introduce any new functions.

It has the advantage that you only need to change one place. Otherwise
you need to check the method structs and the calling register function.

Regards

Marcel



  reply	other threads:[~2012-12-23 16:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-23 15:24 [PATCH BlueZ 1/6] gdbus: Introduce G_DBUS_METHOD_FLAG_EXPERIMENTAL Luiz Augusto von Dentz
2012-12-23 15:24 ` [PATCH BlueZ 2/6] media: Enable RegisterPlayer and UnregisterPlayer methods as experimental Luiz Augusto von Dentz
2012-12-23 15:24 ` [PATCH BlueZ 3/6] gdbus: Introduce GDBusInterfaceFlags Luiz Augusto von Dentz
2012-12-23 16:09   ` Marcel Holtmann
2012-12-23 16:27     ` Luiz Augusto von Dentz
2012-12-23 16:30       ` Marcel Holtmann [this message]
2012-12-23 15:24 ` [PATCH BlueZ 4/6] gdbus: Call check_signals when sending signals with g_dbus_send_message Luiz Augusto von Dentz
2012-12-23 16:10   ` Marcel Holtmann
2012-12-23 16:31     ` Luiz Augusto von Dentz
2012-12-23 16:40       ` Marcel Holtmann
2012-12-23 15:24 ` [PATCH BlueZ 5/6] player: Enable MediaPlayer1 interface as experimental Luiz Augusto von Dentz
2012-12-23 15:24 ` [PATCH BlueZ 6/6] AVRCP: Fix not checking for media_player_controller_create 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=1356280239.29264.28.camel@aeonflux \
    --to=marcel@holtmann.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    /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