Re: [RFC 2/2] doc: Add description for history agent interface

[Denis Kenzior <denkenz@gmail.com>]

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

Hi Mikhail,

> 
> Am I right in assuming that the SMS history roundtrip is not performed before acking the constituent TPDUs to the network? If it is, we have problems even regardless of D-Bus method call timeouts.
> 

This has been discussed to death a bazillion times.  So lets recap very
quickly:

AT modems have two ways of delivering SMS messages:
- CMTI
- CMT

CMTI delivery means the message goes to the SIM / ME store first, and
then signaled up.  The modem takes care of automatically acking the
message in this case.  CMT delivery gives the message straight to the
sms driver and expects messages to be acked.

Here's the problem, half the modems in this world don't support CMTI
delivery, the other half does not support CMT delivery.  oFono core does
not know or care what mechanism is used.  It is the driver's
responsibility to ack the received pdu.

If CMTI delivery is used, then the core has to care about SIM / ME
storage, reading of the SMS store and managing free space -> disaster
area.  Been there, got the t-shirt.

If CMT delivery is used, you have to ack the message in a 'reasonable'
period of time.  If you do not, then the modem silently (e.g. it does
not tell you) turns off SMS delivery.  Of course you can send a negative
ack, however, there is no mechanism that I'm aware of to tell the
network you can receive SMS messages again -> disaster area.

Another fun fact about CMT delivery is that if you do not ack in a
'reasonable' amount of time, the modem _silently_ turns off SMS
delivery.  So putting acks over D-Bus is simply a bad idea.

So oFono:
 1. Parses the SMS
 2. If the SMS is a multi-fragment SMS, it is written to store
2a. If the SMS is the last missing fragment goes to step 2b, otherwise
goes to step 5
2b. re-assembles the sms and removes intermediate store
 3. Signals the SMS over D-Bus / history
 4. Returns control to the driver which is responsible for acking the
SMS if needed.

All of this happens synchronously.  If oFono crashes in steps 1..3, the
message is never acked.  If your history plugin writes to its
intermediate store (which it has to anyway) and fsyncs, there are no issues.

So yes, there might be conditions where you crash before fsync really
completes and you lose the SMS.  However, there's nothing in the world
you can do about this case anyway, since both the write and the fsync
succeeded.

> 1. The history service may be activated on demand by a well-known name.

D-Bus service activation on system bus is not available, please stop
bringing this up.

> If this is in fact mandatory, we'll have problems in making telepathy-ring serve as the history plugin. We want it in the storage path for architectural simplicity: commhistory daemon is by design a Telepathy logger that works basically the same way for all connection managers.
> 
> 2. You don't want multiple entities to observe events pertaining to oFono communication history and be able to control spooling while not being regulated by oFono.
> If this is a concern, I think it's outweighed by greater simplicity and flexibility, and the idea that access policy should be defined outside of the implementation.
> 
> 3. For call history, you need reliable storage of call events before you can proceed handling the call with the interactive client signaling.
> I thought this is entirely up to the application and as such does not have to be in scope for oFono. Correct me if I'm wrong.
> 

Sorry but I do not understand the above two points.  Can you clarify
what exactly you mean here?  The actual history storage is indeed not in
scope of oFono.  That is up to the system integrator to figure out.

Regards,
-Denis