All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: [PATCH 08/12] handsfree: Expose RequestInput in D-Bus API
Date: Fri, 09 Sep 2011 01:01:28 -0500	[thread overview]
Message-ID: <4E69ABB8.4030403@gmail.com> (raw)
In-Reply-To: <1316104483-13144-9-git-send-email-mikel.astiz@bmw-carit.de>

[-- Attachment #1: Type: text/plain, Size: 3772 bytes --]

Hi Mikel,

On 09/15/2011 11:34 AM, Mikel Astiz wrote:
> ---
>  src/handsfree.c |   64 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 64 insertions(+), 0 deletions(-)
> 
> diff --git a/src/handsfree.c b/src/handsfree.c
> index 2bf2284..3138474 100644
> --- a/src/handsfree.c
> +++ b/src/handsfree.c
> @@ -47,6 +47,7 @@ struct ofono_handsfree {
>  	const struct ofono_handsfree_driver *driver;
>  	void *driver_data;
>  	struct ofono_atom *atom;
> +	DBusMessage *pending;
>  };
>  
>  void ofono_handsfree_set_inband_ringing(struct ofono_handsfree *hf,
> @@ -118,11 +119,71 @@ static DBusMessage *handsfree_set_property(DBusConnection *conn,
>  	return __ofono_error_invalid_args(msg);
>  }
>  
> +static void request_phone_number_cb(const struct ofono_error *error,
> +					const struct ofono_phone_number *number,
> +					void *data)
> +{
> +	struct ofono_handsfree *hf = data;
> +	DBusMessage *reply;
> +	const char *phone_number;
> +
> +	if (!hf->pending)
> +		return;

Is this check really necessary?

> +
> +	if (error->type != OFONO_ERROR_TYPE_NO_ERROR) {
> +		DBG("Phone number request callback returned error: %s",
> +			telephony_error_to_str(error));
> +
> +		reply = __ofono_error_failed(hf->pending);
> +		__ofono_dbus_pending_reply(&hf->pending, reply);
> +		return;
> +	}
> +
> +	phone_number = phone_number_to_string(number);
> +	reply = dbus_message_new_method_return(hf->pending);
> +	dbus_message_append_args(reply, DBUS_TYPE_STRING, &phone_number,
> +					DBUS_TYPE_INVALID);
> +	__ofono_dbus_pending_reply(&hf->pending, reply);
> +}
> +
> +static DBusMessage *handsfree_request_input(DBusConnection *conn,
> +						DBusMessage *msg, void *data)
> +{
> +	struct ofono_handsfree *hf = data;
> +	DBusMessageIter iter;
> +	const char *name;
> +
> +	if (hf->pending)
> +		return __ofono_error_busy(msg);
> +
> +	if (dbus_message_iter_init(msg, &iter) == FALSE)
> +		return __ofono_error_invalid_args(msg);
> +
> +	if (dbus_message_iter_get_arg_type(&iter) != DBUS_TYPE_STRING)
> +		return __ofono_error_invalid_args(msg);
> +
> +	dbus_message_iter_get_basic(&iter, &name);
> +
> +	if (g_str_equal(name, "PhoneNumber")) {
> +		if (!hf->driver->request_phone_number)
> +			return __ofono_error_not_supported(msg);
> +
> +		hf->pending = dbus_message_ref(msg);
> +		hf->driver->request_phone_number(hf, request_phone_number_cb,
> +							hf);
> +		return NULL;
> +	}

I'd rather not do it this way.  I know +BINP is supposed to be
'extendable', but it hasn't been in what 5-6 years now?  Using
RequestPhoneNumber or RequestNumberInput would probably be better.

> +
> +	return __ofono_error_invalid_args(msg);
> +}
> +
>  static GDBusMethodTable handsfree_methods[] = {
>  	{ "GetProperties",    "",    "a{sv}", handsfree_get_properties,
>  		G_DBUS_METHOD_FLAG_ASYNC },
>  	{ "SetProperty",      "sv",  "", handsfree_set_property,
>  		G_DBUS_METHOD_FLAG_ASYNC },
> +	{ "RequestInput",      "s",  "v", handsfree_request_input,
> +		G_DBUS_METHOD_FLAG_ASYNC },

You might want to submit a formal API proposal first (e.g. in doc/)
before trying to implement the API.  This would make discussing API
details easier.

>  	{ NULL, NULL, NULL, NULL }
>  };
>  
> @@ -143,6 +204,9 @@ static void handsfree_remove(struct ofono_atom *atom)
>  	if (hf->driver != NULL && hf->driver->remove != NULL)
>  		hf->driver->remove(hf);
>  
> +	if (hf->pending)
> +		dbus_message_unref(hf->pending);
> +

The rest of the code doesn't do this, though it probably should.
However, it probably belongs in _unregister, not _remove.  Using
ofono_dbus_pending_reply might be better as well.

>  	g_free(hf);
>  }
>  

Regards,
-Denis

  reply	other threads:[~2011-09-09  6:01 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-15 16:34 [PATCH 00/12] Bluetooth HFP-specific extensions Mikel Astiz
2011-09-15 16:34 ` [PATCH 01/12] TODO: Task added for HFP-specific capabilities Mikel Astiz
2011-09-09  5:10   ` Denis Kenzior
2011-09-15 16:34 ` [PATCH 02/12] Add handsfree atom " Mikel Astiz
2011-09-09  5:13   ` Denis Kenzior
2011-09-16 15:56   ` Daniel Wagner
2011-09-09  5:14     ` Denis Kenzior
2011-09-15 16:34 ` [PATCH 03/12] hfpmodem: Driver implements handsfree atom Mikel Astiz
2011-09-09  6:14   ` Denis Kenzior
2011-09-15 16:34 ` [PATCH 04/12] hfp_hf: Plugin creates " Mikel Astiz
2011-09-09  6:16   ` Denis Kenzior
2011-09-15 16:34 ` [PATCH 05/12] handsfree: Atom supports inband ringing status Mikel Astiz
2011-09-09  6:15   ` Denis Kenzior
2011-09-15 16:34 ` [PATCH 06/12] hfpmodem: Support for +BSIR unsol. result codes Mikel Astiz
2011-09-09  5:48   ` Denis Kenzior
2011-09-15 16:34 ` [PATCH 07/12] handsfree: Support for number requests (AT+BINP=1) Mikel Astiz
2011-09-09  6:16   ` Denis Kenzior
2011-09-15 16:34 ` [PATCH 08/12] handsfree: Expose RequestInput in D-Bus API Mikel Astiz
2011-09-09  6:01   ` Denis Kenzior [this message]
2011-09-15 16:34 ` [PATCH 09/12] hfpmodem: Support of number requests (AT+BINP=1) Mikel Astiz
2011-09-09  6:04   ` Denis Kenzior
2011-09-15 16:34 ` [PATCH 10/12] handsfree: Read-only voice-recognition D-Bus prop Mikel Astiz
2011-09-09  6:13   ` Denis Kenzior
2011-09-15 16:34 ` [PATCH 11/12] handsfree: Writable voice-recogn. prop (AT+BVRA) Mikel Astiz
2011-09-15 16:34 ` [PATCH 12/12] hfpmodem: Support for AT+BVRA Mikel Astiz
2011-09-09  6:17   ` Denis Kenzior
2011-09-23  8:57 ` [PATCH 00/12] Bluetooth HFP-specific extensions =?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont

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=4E69ABB8.4030403@gmail.com \
    --to=denkenz@gmail.com \
    --cc=ofono@ofono.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.