Re: Please comment on callhistory API

[Marcel Holtmann <marcel@holtmann.org>]

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

Hi Raji,

> >>>> org.ofono.History will be the main adapter interface and 
> >>>> org.ofono.CallHistoryAgent the callhistory agent and 
> >>>> org.ofono.SmsHistoryAgent as the sms history agent. I want to seperate 
> >>>> the two agents so that sms app will expose sms history agent and dialer 
> >>>> will register and expose callhistory agent. Then it will be clear which 
> >>>> agent is interested in which history, vs one org.ofono.HistoryAgent 
> >>>> exposing ReportCall and ReportTextMessage methods. In the later case 
> >>>> adapter needs to flush both smshistory and callsistory onto two agents 
> >>>> even though agents are not interested only in type of history.
> >>>>     
> >>>>         
> >>> actually not really. So why does the dialer and SMS application need to
> >>> register for the history? Isn't that going to be stored central in
> >>> Tracker or something similar. Should not be Tracker or some Tracker
> >>> helper be registering the agent?
> >>>   
> >>>       
> >> No, Dialer and Sms applications are the ones that read and stores 
> >> locally, this will probably move to tracker eventually.
> >> So I dont think we can assume that there is going to be a tracker agent.
> >>     
> >>> I might be wrong, but does it really make sense to separate it on this
> >>> level?
> >>>   
> >>>       
> >> I am thinking by separating the applications will only register and get 
> >> data they are interested in.
> >>     
> >
> > so Denis and I had a long chat about this. And essentially the history
> > agent concept is not really something that we should maintain long term.
> > We need be able to Tracker to listen on the D-Bus system bus and have
> > oFono history plugin send data directly to Tracker. The history plugin
> > should track if Tracker is running or not. If not spool. Otherwise send
> > data to Tracker directly. Everything else is a pretty much complicated
> > design.
> >
> > However for a short term solution, you could do a history agent concept
> > as part of a MeeGo specific plugin.
> >
> > So use org.ofono as D-Bus service name and com.meego.TelephonyHistory
> > and com.meego.TelephonyHistoryAgent as interface names.
> >
> > The main object path is / since are not going to make this based on a
> > per modem.
> >
> > Two method calls in the agent a) ReportVoiceCall a) ReportTextMessage
> > and that is it in. In the info dict include the Modem property which
> > points to the modem object this information originates from.
>  For outgoing TextMessages, ofono updates the history plugin in two method calls, first all the text message history related properties msg id, message , local received time,actual sent time, lineid and status='Pending' and in another method ofono updates plugin with the status. Earlier design, I sent out history record with pending status and  when I received  status update I  used  'property changed'  signal for status update. But I use 'uint32,variant' type which is not consistent with the current ofono property changed signal type. My questions,
>  1) Are you ok with using signal for status update, this lets us send out history as soon as we receive them if the agent is running      
> 
>  2) If we want to avoid signal, then we can store the outgoing text message record until we receive the status update from ofono, combine them and send out in case of agent running. In case of agent not running we do this anyway. 

you can just send the method call (it is not a signal in this case) both
times. When you get the pending one and once the final one. The SMS
contains its own SHA-1 based id. So the history application can easily
update its database. It can be used as primary key. oFono ensures its
uniqueness as good as SHA-1 hash can do.

Regards

Marcel