All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: [PATCH 3/4] gatchat: Emit notification when command is sent to modem.
Date: Fri, 30 Apr 2010 08:31:47 -0500	[thread overview]
Message-ID: <201004300831.47649.denkenz@gmail.com> (raw)
In-Reply-To: <1272606483.22838.180.camel@localhost.localdomain>

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

Hi Marcel,

> Hi Denis,
> 
> > > +/*!
> > > + * Same as g_at_chat_send but with an ability to return a notification
> > > the + * moment the command finally leaves the queue and is submitted to
> > > lower + * layer.
> > > + *
> > > + * This is useful for cases where the modem's response time needs to
> > > be + * measured, assuming that the lower layers processing time is
> > > shorter + * than the minimum accuracy needed.
> > > + */
> > > +guint g_at_chat_send_with_callback(GAtChat *chat, const char *cmd,
> > > +					const char **valid_resp,
> > > +					GAtSubmitNotifyFunc sent,
> > > +					GAtResultFunc func,
> > > +					gpointer user_data,
> > > +					GDestroyNotify notify);
> > > +
> >
> > So I'm fine with the implementation but the name needs work.  Can we use
> > g_at_chat_send_with_submit_notify? Or maybe g_at_chat_send_full, similar
> > to how GLib does it.
> >
> > Perhaps enabling submit_notification for a given command after it has
> > been submitted with g_at_chat_send?
> >
> > e.g. g_at_chat_set_submit_notify(GAtChat *chat, guint command,
> > GAtSubmitNotifyFunc sent, gpointer user_data, GDestroyNotify notify);
> 
> I am not a huge fan of the _full() stuff, but it is actually pretty nice
> for the cases where 99% of users don't care. And this seems to be one of
> them. The send_with_submit_notify() is way too long.

I'm not a fan of _full either, however it is a precedent, so might as well be 
a candidate.

> 
> Maybe g_at_chat_send_and_notify() is an acceptable simple version for
> this or just g_at_chat_submit() and g_at_chat_send() to keep these
> versions apart.

In my opinion send_and_notify does not convey enough information about what 
the function is trying to do.  _submit is even less clear.  API should be very 
clear on its intent just from the function name without needing to consult 
documentation.

Out of all these so far my vote is on send_full just because it is familiar to 
folks using GLib...  We might have to cut down some of the parameters to _send 
as well (like GDestroyNotify argument) if we introduce send_full.

Regards,
-Denis

  reply	other threads:[~2010-04-30 13:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-29 11:32 [PATCH 3/4] gatchat: Emit notification when command is sent to modem Andrzej Zaborowski
2010-04-30  3:00 ` Denis Kenzior
2010-04-30  5:48   ` Marcel Holtmann
2010-04-30 13:31     ` Denis Kenzior [this message]
2010-04-30 13:41       ` Marcel Holtmann
2010-05-03 18:22     ` andrzej zaborowski
2010-05-04  9:07       ` Marcel Holtmann
2010-05-04 13:11         ` Andrzej Zaborowski

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=201004300831.47649.denkenz@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.