All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: ofono@ofono.org
Subject: Re: Description of Voice call history plugin patch
Date: Fri, 17 Sep 2010 17:16:49 +0900	[thread overview]
Message-ID: <1284711409.2405.192.camel@localhost.localdomain> (raw)
In-Reply-To: <1284682387-22768-1-git-send-email-Rajyalakshmi.Bommaraju@intel.com>

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

Hi Raji,

> Callhistory is a plugin loaded by ofono for persisting voice call history information in a disk file. Plugin exports dbus methods and signals as org.ofono.callhistory interface. Whenever there is a voice call in the system, ofono calls the plugin with the infomation (lineid,calltype,start time, end time) , plugin writes the information into the file , increments the 'unread' field in the header and sends out dbus signal with the number of unread records. Client (dialer) requests history records by calling method "GetVoiceHistory" exposed on the callhistory interface. After receiving information client calls the "SetVoiceHistoryRead" as an acknowledgement to indicate end of transaction. The pointers in the header are adjusted appropriately (explained clearly below).
> 
> Design : Plugin uses memory mapped file for high performance input/output operations. File is used as cyclic queue for storing or reading records, it store s 50 records of 78bytes,hence fixed size file of 3916 bytes is used. File's first 16 bytes were used for storing header, and next 3900 bytes for data. Header structure has head pointer, tail pointer,unread and lastid. Head pointer points to next slot for writing record into,tail for reading record, unread for number of history records unread by client, lastid for id of the last record that is written.

I am not buying into this performance argument at all. How many calls to
you expect per second.
 
> When the plugin is loaded by the ofono, it opens or creates a disk file of 3916 bytes size and maps it into fixed size memory space. Plugin reads the header of the file , if the 'unread' records is > 0 , a signal is sent out on the dbus with the information of number of unread records. 
> 
> Requesting data by client: 
> When the client calls "GetVoiceHistory" method,plugin uses temp_tail and temp_unread variables to accomplish sending data to client. It copies tail pointer stored in the header into temporary tail pointer ,starts to read history records one at a time from the location pointed by the temp tail pointer , copies the into dbus structure, increments the temp tail pointer by size of the history record (78 bytes) and reads data from the next record location , this is repeated until it reaches head pointer. when all the unread records are read then the dbus structure is sent to the client. Once the data received, client needs to "SetVoiceHistoryRead" method to indicate that it received the data. Plugin will update the tail pointer with the temp tail pointer and unread records number is decremented by temp_unread. Using temp_tail and temp_unread variables protect from modifying the header if there is any loss in data delivery. If client doesnt call 'SetVoiceHistoryRead' then the actua
>  l header pointers wont be updated in the file. 
> 
> Writing record into the file:
> When Ofono calls the plugin with call information (phone number, call type, call start time , call end time), plugin increaments the lastid to create record id for this record ,writes the record in the location pointed by head, and the head pointer is incremented by size of record (78 bytes), "unread" variable is incremented by 1. If the head reaches end of file (3916) then it is reset it back to begining of the data portion of the file (16 bytes). A dbus signal is sent out with number of current unread records. Plugin keeps writing the records in circular queue.

This sounds all way too complicated. And the D-Bus API design is
actually racy since there is no clear access control on the history
information.

I think the proper solution is to create a call history plugin that
creates a D-Bus interface for a call history agent.

That way we know when an agent is present to consume history information
and only if none is present we have to cache it on disk. And once an
agent becomes available flush the cached information.

And the cache should be just be done with a simply appending to a file
and then truncating it after reading it.

Regards

Marcel



  parent reply	other threads:[~2010-09-17  8:16 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-17  0:13 Description of Voice call history plugin patch Rajyalakshmi Bommaraju
2010-09-17  0:13 ` [PATCH] plugins: Adding implementation for persisting voice call history Rajyalakshmi Bommaraju
2010-09-17  1:14   ` Marcel Holtmann
2010-09-17  3:17 ` Description of Voice call history plugin patch Denis Kenzior
2010-09-17  6:32   ` Bommaraju, Rajyalakshmi
2010-09-17  8:07     ` Marcel Holtmann
2010-09-17  8:16 ` Marcel Holtmann [this message]
2010-09-17 18:00   ` Bommaraju, Rajyalakshmi
2010-09-17 23:41     ` Marcel Holtmann
2010-09-20 18:52   ` Bommaraju, Rajyalakshmi
2010-09-21  2:37     ` Marcel Holtmann

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=1284711409.2405.192.camel@localhost.localdomain \
    --to=marcel@holtmann.org \
    --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.