Hi Mikhail,

> I totally agree. But it means that you have code in oFono to reliably store an ordered collection of stuff in a filesystem. I wouldn't like MeeGo developers to maintain very similar code in a different component, just for API adaptation reasons.

No we do not.  We have code to reliably store tpdus, fragments not
re-assembled messages.  It is not ordered or anything else you make it
out to be.  Why don't you actually read the sms_assembly code and tell
me if it is usable for anything else.  The code for storing assembled
messages would be _completely_ different.

> D-Bus messages at initialization of a storage-capable client:
> 
> 1. client connects to the oFono signal NewMessage.
> 2a. client calls ListMessages.
> 2b. oFono returns spooled messages.
> 
> If there are any messages, two more are needed:
> 
> 3a. client calls ExpungeMessages.
> 3b. oFono returns.
> 
> When a new message is received:
> 
> 1. oFono emits a NewMessage signal.
> 2a. client calls ExpungeMessages.
> 2b. oFono returns.
> 
> Now if we implement a history plugin to serve this API, there will be all of the above plus the history plugin registration and event storage roundtrips.

You are proving Marcel's point here, the Agent has about 1/2 as many
round trips as your proposal.

1. client calls RegisterAgent()
2. For each new message the agent's HandleMessage() method is called
3. Client calls UnregisterAgent or oFono calls Release()

Regards,
-Denis