+ void MessageReceived(dict info) + + Incoming text message. + + The info dictionary contains 'Identifier', 'Sender', + 'Text', 'LocalTime' and 'RemoteTime' properties. + + Possible Errors: None

-----Original Message----- From: ofono-bounces(a)ofono.org [mailto:ofono-bounces@ofono.org] On Behalf Of ext Marcel Holtmann Sent: Wednesday, February 02, 2011 6:44 PM To: ofono(a)ofono.org Subject: RE: [RFC 2/2] doc: Add description for history agent interface > here's a few comments about the SMS delivery part. These apply to > the history plugin interface as well, so not specifically only about > this patchset. and this is just a RFC so I really want comments. > > + void MessageReceived(dict info) > > + > > + Incoming text message. > > + > > + The info dictionary contains 'Identifier', 'Sender', > > + 'Text', 'LocalTime' and 'RemoteTime' properties. > > + > > + Possible Errors: None > > If this is the primary way to deliver SMS'es reliably, then this > raises some problems. Take these more as discussion points. I'm looking > this in terms of gaps to what we have implemented in past > products (e.g. N900). The history API is the primary way to get messages stored reliable in a database. This D-Bus API is intended to get accross the system/session bus boundary and allow this for Tracker integration. For example with commhistory-daemon or something similar. > - This history agent has no error handling for SMS storage. In case > device storage is full, or device is malfunctioning otherwise, > the messages should not be acked to network as stored. > - This relates to another TODO -> persistant storage of RX-TPDUs > for incomplete messages. If we've acked a TPDU to network, > we must have stored it to persistant storage. Where are we not doing this. We do store the fragments. If it is a complete message, we signal it directly. > - The history agent does not wait until the agent replies it has > handled the message, but instead it calls agent_request_dispatch > and then already returns to core (which acks the message to modem). So > if you run out of battery (or some more abrupt cause) at this > point, you will lose messages. > - The smshistory ofono plugin at http://repo.meego.com/MeeGo/builds/trunk/daily/handset/repos/source/sms history-0.1.8-1.7.src.rpm > ... solves this part, but I wonder whether it's ok to block > the ofono event loop until disk i/o is fully synced (this can > take suprisingly long on a loaded system). I know this actually. The missing piece is the storing to disk here to spool the SMS history and call history in case no agent is present. > I'd prefer to have something like: > http://people.freedesktop.org/~wjt/telepathy-spec- import_stored_messages/spec/Connection_Interface_Stored_Messages.html > > This approach has many benefits: > - it allows more flexibility to how the persistant i/o is > implemented (you don't have to complete i/o during DBus > method->reply, or during a single function callback), > - the agent can recover if device is shutdown when there are > some messages in the TPDU spool, but not acked to message > store (upon restart, commhistory client will ask any pending > messages from the spool) How is this any better? If all messages get send when the agents registers to oFono. And we can easily use D-Bus results to either delete messages from the spool or not. Since D-Bus is asynchronous and that will just work out fine.

This is not just about SMS actually. It is also for call history. So the history plugin needs to take care of the spooling and from there it can go directly into the database like Tracker.

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.

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.

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.

-----Original Message----- From: ofono-bounces(a)ofono.org [mailto:ofono-bounces@ofono.org] On Behalf Of ext Marcel Holtmann Sent: Thursday, February 03, 2011 1:13 AM To: ofono(a)ofono.org Subject: RE: [RFC 2/2] doc: Add description for history agent interface > > 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. > > I think this is perfectly reasonable. Even if some storage system > had some internal caches outside the kernel sync's reach, I'd imagine > flushing these would be a prime candidate for last-minute actions done > before battery dies (or some sensor detecting the device is about to > hit a brick wall in about a few milliseconds ;)). so the device health or charging daemon or whatever will most likely shut down the device cleanly before the battery dies completely. The case that a device suddenly dies, because the battery is empty does not really exist.

> So handling this might still be useful even if reliable re-enabling > of messages would not work reliably (assumption being that recycling > and reregistering will reliably reenable message delivery). Or do you Last I checked 27.005 mentions nothing on the behavior of sms store full conditions or naking. So all of this would be highly entertaining for someone to discover ;)

There is still the practical considerations of when / if to start naking messages. Remember you can have multiple history plugins, so what if the first one succeeds but the second one fails?

In the end the ack feature was meant for SIM/ME store and out of memory conditions for the very limited storage those devices had. Since the

>> So yes, there might be conditions where you crash before fsync >> really completes and you lose the SMS. However, there's nothing in the > > I think this is perfectly reasonable. Even if some storage system > had some internal caches outside the kernel sync's reach, I'd imagine Of course, fsync is the best you can do. I'm just pointing out that even with fsync you're not guaranteed to 'safely' receive the SMS. You

-----Original Message----- From: ext Denis Kenzior [mailto:denkenz@gmail.com] Sent: Wednesday, February 02, 2011 9:23 PM To: ofono(a)ofono.org Cc: Zabaluev Mikhail (Nokia-MS/Helsinki) Subject: Re: [RFC 2/2] doc: Add description for history agent interface 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.

> 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.

> 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.

> How is this any better? If all messages get send when the agents > registers to oFono. And we can easily use D-Bus results to either > delete > messages from the spool or not. Since D-Bus is asynchronous and that > will just work out fine. 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 is not just about SMS actually. It is also for call history. So > the > history plugin needs to take care of the spooling and from there it can > go directly into the database like Tracker. Is it necessary/more practical to register a history service callable by oFono, rather than just signal change events and provide methods for a client to acknowledge that it has handled them? I can see a few reasons why the explicit history service API might be needed: 1. The history service may be activated on demand by a well-known name. 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.

> I am not really getting what you are saying. oFono will reassembly the > message for you piece by piece. And we are making sure fragments are > stored reliably. However once the message is complete we give it to > history for further processing. Mainly to get it stored in the > database. The part I don't get is, if you do store TPDUs reliably as you seem to be required to do anyway, why not keep the assembled messages until the client tells you that it is no longer interested in them? This will remove a whole class of issues with history agent's availability, reliability, and performance.

> If you can accept this extra risk factors in the architecture and > ensure > that everything is reliable that is fine with me. You do might have to > design your unique history plugin that interacts directly with TP-ring > then. And to that extend also has its own spool. It does not have to, if we can implement StoredMessages in terms of oFono. If we could expunge messages from oFono spool explicitly rather than by serving a method call roundtrip, it would be natural. In all, we need three things from the oFono SMS API: * a property listing the spooled messages; * a method to expunge some of the messages; * a signal notifying of a new message in the spool.

And this obviates the need to have a history agent service, if I understood correct that you actually don't care about enforcing reliable storage for call events on oFono side. >> 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. > > The example that I sent around here was clearly limited to one consumer > and one consumer only. And that on purpose. I think that every storage > entity. Being it commhistory alone, or Tracker alone or all together > with TP-ring, they need a special history plugin to serve the exact > purpose. So a platform integrating oFono cannot choose to implement call and message logging separately. It needs to supply the whole hog in one plugin, and filter out the events it is not interested in at this level.

> >> I am not really getting what you are saying. oFono will reassembly > the > >> message for you piece by piece. And we are making sure fragments are > >> stored reliably. However once the message is complete we give it to > >> history for further processing. Mainly to get it stored in the > >> database. > > > > The part I don't get is, if you do store TPDUs reliably as you seem > to be required to do anyway, why not keep the assembled messages until > the client tells you that it is no longer interested in them? > > This will remove a whole class of issues with history agent's > availability, reliability, and performance. > > How exactly is this different from the history plugin storing the > message and letting client ack it? You can implement that now with > history easily enough. True, but it will look like oFono does 90% of the work needed -- and then hands it to the history plugin which basically redoes it, only to offer a more convenient API.

> Not everyone has the same requirements here, you can have systems with > a > well defined store that do not need to cross the system/session bus > boundary for instance. They could use the pull-style API as well, having a push method with a 100% success rate requirement is not necessary for this.

> > In all, we need three things from the oFono SMS API: > > * a property listing the spooled messages; > > * a method to expunge some of the messages; > > * a signal notifying of a new message in the spool. > > > > As I mentioned before, you can do that now using history anyway. But > in > the general case I do not agree this belongs as an official API. Who > guarantees acking of messages? Control plane acking is guaranteed by oFono core itself, as we seem to have established. A client then clears the spool, if the system is not dysfunctional.

> How many messages to spool? The filesystem is the only real limit. In a properly working system, you won't have to spool too many messages.

> When to throw away messages? When the client tells you to.

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.

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.

> > 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. Why, you already cache fragments by their respective message refs efficiently. The only thing missing is a thin API to provide a view on complete messages.

> > 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() An interesting question here: should oFono core monitor NameOwnerChanged for the agent's service name, just in case it disappears from the bus? What's the failure mode for this case?

> 2. For each new message the agent's HandleMessage() method is called 2a. agent returns. So the ratio is 2/3 for the only event flow that is relevant for performance, more likely. But I agree, it's a bit more efficient for simple plugins, provided that they never fall off the bus.

Hi, > -----Original Message----- > From: ofono-bounces(a)ofono.org [mailto:ofono-bounces@ofono.org] On > Behalf Of ext Marcel Holtmann > Sent: Friday, February 04, 2011 8:13 PM > To: ofono(a)ofono.org > Subject: RE: [RFC 2/2] doc: Add description for history agent interface > >> Why, you already cache fragments by their respective message refs > efficiently. >> The only thing missing is a thin API to provide a view on complete > messages. > > we are not storing the complete message. We give it to the history API. Somehow we never got to the "because" part in this discussion. Or is it a dogma in oFono?

Sorry, I only jumped into the discussion after it has started and did not read the patch. But now that I do, I see an additional AddMatch and a GetOwnerName in this flow. And the failure mode of the agent disconnecting is... to drop events on the floor???

-----Original Message----- From: ofono-bounces(a)ofono.org [mailto:ofono-bounces@ofono.org] On Behalf Of ext Marcel Holtmann Sent: Friday, February 04, 2011 9:02 PM To: ofono(a)ofono.org Subject: RE: [RFC 2/2] doc: Add description for history agent interface > And the failure mode of the agent disconnecting is... to drop events on the floor??? Who said that? D-Bus is an asynchronous message bus with a method call and a method return message. Where do you see events being dropped?

Hi, > -----Original Message----- > From: ext Denis Kenzior [mailto:denkenz@gmail.com] > Sent: Friday, February 04, 2011 7:06 PM > To: ofono(a)ofono.org > Cc: Zabaluev Mikhail (Nokia-MS/Helsinki) > Subject: Re: [RFC 2/2] doc: Add description for history agent interface > >> 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. Why, you already cache fragments by their respective message refs efficiently. The only thing missing is a thin API to provide a view on complete messages.

So the ratio is 2/3 for the only event flow that is relevant for performance, more likely. But I agree, it's a bit more efficient for simple plugins, provided that they never fall off the bus.

> In the text message case we already provide the history plugin with > _everything_ that it needs. If you want to implement a particular API, > then history is the right avenue to do so. There is no inherent > benefit > of having oFono core do so and we do not want to introduce the concept > of a message store into oFono anyway. > > > So the ratio is 2/3 for the only event flow that is relevant for > performance, more likely. > > But I agree, it's a bit more efficient for simple plugins, provided > that they never fall off the bus. > > Lets put it this way, your proposal is 1.5x slower in the absolute best > case; worse if multiple clients subscribe to the signal, purposefully > or otherwise. Nah, a signal delivery works like a multicast, whereas if you have multiple history agents to get notified about one event, you have to make a full method roundtrip to every one of them.

> Falling off the bus has nothing to do with this performance. You can > make your history plugin detect the 'falling off the bus' events and > handle them appropriately (e.g. spool messages internally until the > consumer comes back.) This is not implemented in the proposed patch. But I like how we are slowly getting to the idea that spooling whole messages in oFono core is necessary anyhow :)

> one of the really early design choices was to not expose TPDU outside > of > oFono core. We do not give TPDUs to history nor do we hand them out > over > D-Bus. That is a fundamental design decision and even after over 2 > years > that is still the right one. 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.

> > > Not everyone has the same requirements here, you can have systems > with > > > a > > > well defined store that do not need to cross the system/session bus > > > boundary for instance. > > > > They could use the pull-style API as well, having a push method with > a 100% success rate requirement is not necessary for this. > > Can someone please sit down and start counting the number of D-Bus > messages and wakeup that are caused by exposing the message objects > instead of using an agent. 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. > And without using an agent you have no access control of who acks > messages. You do, it's controlled by the security framework in D-Bus. Without checking security tokens, you cannot trust the agent, either.

> And additionally oFono does not store the read/unread states > either. It doesn't have to in my proposal. > oFono does not implement a message store. ... while implementing a large part of the functionality needed for a simple intermediate message spool.

> > > > In all, we need three things from the oFono SMS API: > > > > * a property listing the spooled messages; > > > > * a method to expunge some of the messages; > > > > * a signal notifying of a new message in the spool. > > > > > > > Who > > > guarantees acking of messages? > > > > Control plane acking is guaranteed by oFono core itself, as we seem > to have established. > > A client then clears the spool, if the system is not dysfunctional. > > I come to think that you are mixing up full SMS and TPDUs heavily here. > Please get straight what you want. As I explained above, the TPDUs are > oFono core business and not visible anywhere else. oFono only hands out > fully re-assembled messages. That's what I mean too.

> > > How many messages to spool? > > > > The filesystem is the only real limit. In a properly working system, > you won't have to spool too many messages. > > Where, when, how. The spool is cleared at a time when a client is running, for example when the user session starts up. The storage agent's lifetime does not have to be tied to the lifetime of oFono, as one benefit.

> As I said above, normally this should go like this: > > oFono -> history plugin -> message store > oFono -> history plugin -> call history store > > If the history plugin needs to spool, then that is fine. oFono is not > spooling for history plugin since there can be an unlimited number of > history plugin for various use cases. If you collapse "history plugin" into oFono under a more handy pull-style API, there can just as well be unlimited number of client usages for various use cases. Moreover, some of the actually confirmed use cases, in MeeGo no less, can be implemented in a simpler, less wasteful way.

> > > When to throw away messages? > > > > When the client tells you to. > > Which client? What happens if you have more then one client attempting > to access the messages This is not a crime and may actually be useful?

> or even acknowledge them. This means either that the system is misconfigured, or the access control is too permissive.

> If you wanna go via Telepathy, then you most likely need a Telepathy > specific history plugin. My example gave you a basic skeleton for it > and > you just need to add the on-disk spooling to it. That's what we will most likely do, but it's an unnecessary stage.

> - This relates to another TODO -> persistant storage of RX-TPDUs > for incomplete messages. If we've acked a TPDU to network, > we must have stored it to persistant storage. Where are we not doing this. We do store the fragments. If it is a complete message, we signal it directly.

> - The history agent does not wait until the agent replies it has > handled the message, but instead it calls agent_request_dispatch > and then already returns to core (which acks the message to modem). I know this actually. The missing piece is the storing to disk here to spool the SMS history and call history in case no agent is present.

> I'd prefer to have something like: > http://people.freedesktop.org/~wjt/telepathy-spec- > import_stored_messages/spec/Connection_Interface_Stored_Messages.html How is this any better? If all messages get send when the agents registers to oFono. And we can easily use D-Bus results to either delete messages from the spool or not. Since D-Bus is asynchronous and that will just work out fine.