From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: [PATCH 2/2] Added SQLite history plugin
Date: Wed, 07 Apr 2010 13:27:48 -0500 [thread overview]
Message-ID: <201004071327.48885.denkenz@gmail.com> (raw)
In-Reply-To: <97D5E1BB8FC13D4EA3B34BAE8E6898C9C141100E@orsmsx508.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1715 bytes --]
Hi Waldo,
>
> Currently the modem driver acknowledges the PDU right away. If there was a
> notification back to the modem driver, the PDU acknowledgement could be
> delayed till that point in time. If something bad happens in between,
> either the modem or the network can hold on to the PDU and redeliver once
> oFono is up and running again.
>
> Looking at at_cmt_notify() the current implementation might have that
> affect already, as AT+CNMA is only send after calling
> ofono_sms_deliver_notify(). So as long as ofono_sms_deliver_notify() is
> handled synchronously and ensures that the PDU is stored one way or
> another before returning, it will work in case of a crash. (Would like to
> see assumptions like that called out in the code) That said, if your
> storage has issues (disk full?) there is currently no way to let the modem
> driver know that delivery was unsuccessful.
You described the current implementation perfectly. The driver can assume
that the fragment has been stored after the call to sms_deliver_notify has
returned. For its part, the history plugin should ensure the storage is
synced when any of the callbacks are called.
I freely admit the lack of documentation, and if this is a comment you want to
add in the driver definition file I would gladly accept it. However, up to this
point we've only had a single driver for SMS and it gets this part right.
The disk full case we're aware of. Again, this can easily be avoided or
minimized by notifying the user of such conditions in advance. This was an
important use case for devices with 512K of storage, much less so for devices
with 64GB of storage.
Regards,
-Denis
next prev parent reply other threads:[~2010-04-07 18:27 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-06 10:43 [PATCH 2/2] Added SQLite history plugin Dario
2010-04-06 17:56 ` Denis Kenzior
2010-04-07 8:50 ` Dario
2010-04-07 17:01 ` Denis Kenzior
2010-04-07 17:54 ` Nicola Mfb
2010-04-07 18:05 ` Denis Kenzior
2010-04-07 19:20 ` Nicola Mfb
2010-04-07 19:33 ` Denis Kenzior
2010-04-07 21:26 ` Nicola Mfb
2010-04-07 11:47 ` Nicola Mfb
2010-04-07 17:28 ` Bastian, Waldo
2010-04-07 17:33 ` Denis Kenzior
2010-04-07 17:43 ` Nicola Mfb
2010-04-07 17:55 ` Denis Kenzior
2010-04-07 18:09 ` Nicola Mfb
2010-04-07 18:20 ` Denis Kenzior
2010-04-07 18:03 ` Bastian, Waldo
2010-04-07 18:27 ` Denis Kenzior [this message]
2010-04-07 19:28 ` Denis Kenzior
-- strict thread matches above, loose matches on Subject: below --
2010-04-04 21:51 Dario
2010-04-05 2:54 ` Bastian, Waldo
2010-04-06 10:55 ` Dario
2010-04-06 16:12 ` Bastian, Waldo
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=201004071327.48885.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.