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

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

[Marcel Holtmann]

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

---
 doc/history-agent-api.txt |   83 +++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 83 insertions(+), 0 deletions(-)
 create mode 100644 doc/history-agent-api.txt

diff --git a/doc/history-agent-api.txt b/doc/history-agent-api.txt
new file mode 100644
index 0000000..373974d
--- /dev/null
+++ b/doc/history-agent-api.txt
@@ -0,0 +1,83 @@
+History hierarchy
+=================
+
+Service		org.ofono
+Interface	org.ofono.History
+Object path	[variable prefix]/{modem0,modem1,...}
+
+Methods		void RegisterAgent(object path)
+
+			Registers an agent which will be called whenever a
+			new history update is available.
+
+			Possible Errors: [service].Error.InvalidArguments
+			                 [service].Error.InvalidFormat
+
+		void UnregisterAgent(object path)
+
+			Unregisters an agent.
+
+			Possible Errors: [service].Error.InvalidArguments
+
+
+History Agent hierarchy
+=======================
+
+Service		unique name
+Interface	org.ofono.HistoryAgent
+Object path	freely definable
+
+Methods		void CallEnded(dict info)
+
+			Call has been established and finished now.
+
+			The info dictionary contains 'Direction', 'Number',
+			'Name', 'StartTime' and 'EndTime' properties.
+
+			Possible Errors: None
+
+		void CallMissed(dict info)
+
+			Call has been missed.
+
+			The info dictionary contains 'Number', 'Name' and
+			'LocalTime' properties.
+
+			Possible Errors: None
+
+		void MessageReceived(dict info)
+
+			Incoming text message.
+
+			The info dictionary contains 'Identifier', 'Sender',
+			'Text', 'LocalTime' and 'RemoteTime' properties.
+
+			Possible Errors: None
+
+		void MessageSubmitted(dict info)
+
+			Outgoing text message that is currently queued up.
+
+			The info dictionary contains 'Identifier', 'Receiver',
+			'Text' and 'LocalTime' properties.
+
+			Possible Errors: None
+
+		void MessageStatus(dict info)
+
+			Update on the status of outgoing messages.
+
+			The info dictionary contains 'Identifier', 'Status'
+			and 'LocalTime'	properties.
+
+			Status can be 'pending', 'submitted', 'submit-failed',
+			'delivered' or 'deliver-failed'.
+
+			Possible Errors: None
+
+		void Release() [noreply]
+
+			Agent is being released, possibly because of daemon
+			terminating or modem being turned off.
+
+			No UnregisterAgent call is needed.
-- 
1.7.3.5

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

[Kai.Vehmanen]

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

Hi,

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.

On 01 Feb 2011, Marcel Holtmann wrote:
> +		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).

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

- 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/smshistory-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'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)
 
This has been succesfully used in N900 for reliable delivery of 
SMS'es. In N900/MeeGo this would be used by commhistorydaemon (
http://wiki.meego.com/Architecture/Documentation/Communications/Telephony_IM )
which stores the messages to Tracker, and upon completing
commit to persistant storage, it removes the message from
message spool with a explicit DBus method (StoredMessages.ExpungeMessages)

Any comments to this?

PS You could of course solve this out-of-ofono by having 
   one more disk spool in between, but then you'd have 
   three spools already:
     - the yet-to-be-implemented RX-TPDU spool (plugins don't have 
       visibility to TPDUs so this must be done in core)
     - out-of-tree spool for full messages (something like the existing
       smshistory plugin)
     - final store (e.g. Tracker on MeeGo)
   But I'd much rather live with just two spools (one for TPDUs
   and the final storage).

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

[Marcel Holtmann]

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

Hi Kai,

> 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/smshistory-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 has been succesfully used in N900 for reliable delivery of 
> SMS'es. In N900/MeeGo this would be used by commhistorydaemon (
> http://wiki.meego.com/Architecture/Documentation/Communications/Telephony_IM )
> which stores the messages to Tracker, and upon completing
> commit to persistant storage, it removes the message from
> message spool with a explicit DBus method (StoredMessages.ExpungeMessages)
> 
> Any comments to this?

See comment above. This is nothing different than just using the agent
callback to retrieve them.

> PS You could of course solve this out-of-ofono by having 
>    one more disk spool in between, but then you'd have 
>    three spools already:
>      - the yet-to-be-implemented RX-TPDU spool (plugins don't have 
>        visibility to TPDUs so this must be done in core)
>      - out-of-tree spool for full messages (something like the existing
>        smshistory plugin)
>      - final store (e.g. Tracker on MeeGo)
>    But I'd much rather live with just two spools (one for TPDUs
>    and the final storage).

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.

Regards

Marcel

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

[mikhail.zabaluev]

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

Hi,

> -----Original Message-----
> From: ofono-bounces(a)ofono.org [mailto:ofono-bounces(a)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.

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.

Best regards,
  Mikhail

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

[Denis Kenzior]

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

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

[Kai.Vehmanen]

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

Hi Denis,

On 02 Feb 2011, Denis Kenzior wrote:
> 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.

ack, very much agreed. And now that I realized RX fragment spooling
is in fact already done (sorry for the hassle), all is good 
then for this part.

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

So as long as the history plugin spools the message before
returning back in (4), the whole path is safe.

One corner case missing is:

> 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 as ofono_sms_deliver_notify() never returns an error,
we can't handle the case where e.g. device has run out 
of storage, or other severe malfunction (some system component
crashed). I guess the main worry is to stop messages going
to /dev/null, and less about how to recover. I think these cases
are of such severity that the user must anyways at least reboot 
the device, or even have to take it to customer care (or something 
in between). Just with normal device usage (e.g. by trying to
fill device with user content), this should never happen, so 
the reason must be something more fatal.

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 have 
practical experience of cases where even a power cycle won't help...
(e.g. 23.040 specificly handles this scenario so modems should
handle this correctly)?

Oh well, I have to ask around about this as well... perhaps something
we could ignore.

> 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 ;)). 
And in general, fsync should just be enough:
http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/

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

[Marcel Holtmann]

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

Hi Kai,

> > 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. At least with all the charging magic these days that would
be pretty bad for the device and the battery. I would expect a clean
kill of the oFono daemon and I bet you that even have time to shutdown
the modem properly. So even the modem can save all its states.

Regards

Marcel

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

[mikhail.zabaluev]

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

Hi,

> -----Original Message-----
> From: ofono-bounces(a)ofono.org [mailto:ofono-bounces(a)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.

Obviously you never dropped a phone on the floor so luckily that the battery pops out :)
There are also kernel crashes, and I wouldn't always trust the system daemons to perform a graceful shutdown.
There is no excuse to not using reliable persistence mechanisms when 1) they are readily available; 2) their usage is mandated by certification requirements.

Best regards,
  Mikhail

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

[Denis Kenzior]

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

Hi Kai,

> 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 have 
> practical experience of cases where even a power cycle won't help...
> (e.g. 23.040 specificly handles this scenario so modems should
> handle this correctly)?

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 ;)

The number of AT modems that utterly mess up SMS is amazing.  Have a
look at drivers/atmodem/sms.c sometime, particularly grep for VENDOR.
And that driver is sane compared to things I've seen elsewhere.

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?  What if this was just a
transient error and you are now silently blocking the user from
receiving SMSes?  Is it better to drop a single SMS or lots of them?
How do you notify the user something is wrong?

Catastrophic conditions really need to be taken care of by self test /
device health management.  If a hardware fault is detected, then panic
and shutting down as many devices (including the modem) is probably wise.

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
user was managing the SMS store, it made sense to have this capability.
 Modern systems are a totally different animal.

>> 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 ;)). 
> And in general, fsync should just be enough:
> http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/

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
can still get astronomically unlucky: fsync, ack the message but still
crash before it has a chance to appear on the physical media or corrupt
the filesystem some other way.

Regards,
-Denis

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

[Kai.Vehmanen]

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

Hi,

On 03 Feb 2011, Denis Kenzior wrote:
>> 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 ;)

yeah true. I don't think implementing this with AT modems makes
much sense. I was more thinking whether this should be possible with 
oFono and modems, which provide a more sane interface (e.g. isimodem,
see drivers/isimodem/sms.c:send_deliver_report()).

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

True. If (and that's potentially a big if) this is implemented,
a separate method on org.ofono.MessageManager for stopping
delivery might be a better option. Hmm, although, if this is now
only used in case of device malfunction, then you could just as well
put the modem offline (works with AT modems as well). So let's just 
drop this, unless someone feels more strongly.

> 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

Yes, much of the specs have been written with this is mind, and
I agree, this is out-of-scope for oFono.

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

Bad wording on my side: I was trying to say that I very much
agree with you on this. We are not controlling nuclear reactors
with SMS messages (at least not yet ;)), so no need to go overboard.

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

[mikhail.zabaluev]

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

Hi,

> -----Original Message-----
> From: ofono-bounces(a)ofono.org [mailto:ofono-bounces(a)ofono.org] On
> Behalf Of ext Denis Kenzior
> Sent: Thursday, February 03, 2011 9:13 AM
> To: ofono(a)ofono.org
> Cc: Vehmanen Kai (Nokia-MS/Tampere)
> Subject: Re: [RFC 2/2] doc: Add description for history agent interface
> 
> 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
> can still get astronomically unlucky: fsync, ack the message but still
> crash before it has a chance to appear on the physical media or corrupt
> the filesystem some other way.

No, that should be taken care of by fsync and filesystem journaling in non-broken systems.
If your filesystem storage has a writeback cache that you cannot flush, you are screwed no matter what you do, of course.

Best regards,
  Mikhail

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

[mikhail.zabaluev]

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

Hi Denis,

> -----Original Message-----
> From: ext Denis Kenzior [mailto:denkenz(a)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.

Sorry, I'm quite new to oFono.
My gut instinct tells me that oFono should be able to hide the difference by providing CMTI-like spool semantics to the client in all cases. But I might be missing quite a lot of background here.

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

So, it's less disastrous if you implement some file-backed spool for both models.

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

But this means that you do put a D-Bus roundtrip (step 3) in the loop for acks --> bad idea?
Also, the first fragment may not be acked until you got the whole message AND confirmed to have stored it? Can it even work reliably in all networks?

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

Really? OK, scratch that.

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

True. My point is, there is no real need for a dedicated "history storage" service on the oFono level.

Best regards,
  Mikhail

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

[Denis Kenzior]

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

Hi Mikhail,

On 02/03/2011 05:57 AM, mikhail.zabaluev(a)nokia.com wrote:
> Hi Denis,
> 
>> -----Original Message-----
>> From: ext Denis Kenzior [mailto:denkenz(a)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.
> 
> Sorry, I'm quite new to oFono.
> My gut instinct tells me that oFono should be able to hide the difference by providing CMTI-like spool semantics to the client in all cases. But I might be missing quite a lot of background here.
> 

Actually that is not what we want.  CMTI is pretty damn slow since you
have to store on the SIM first, then signal the core.  And the core has
to delete from the SIM as well.  CMT skips the first step and goes
straight to the core, only the ack is required.

>> 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.
> 
> So, it's less disastrous if you implement some file-backed spool for both models.
> 

And this is what we do, no?

>> 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.
> 
> But this means that you do put a D-Bus roundtrip (step 3) in the loop for acks --> bad idea?
> Also, the first fragment may not be acked until you got the whole message AND confirmed to have stored it? Can it even work reliably in all networks?

We do not have a D-Bus roundtrip for the ack.  The ack always happens as
soon as the fragment is delivered.  It is assumed to hit the disk
synchronously in step 2 (for multi-fragment) or step 3 (in history).

Regards,
-Denis

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

[Marcel Holtmann]

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

Hi Mikhail,

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

we are not delivering TPDUs to history, we are delivering messages.
oFono will reassemble the segments for you. This is oFono's job.

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.

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

oFono is running as system service. It can not interact directly with
Tracker or Telepathy since both are only available on the session bus.

If you wanna activate some session bus based history service then that
is out of the scope of oFono.

As I explained to Kai on IRC, I would personally not go via Telepathy
since it is one extra (or even multiple) piece in the puzzle for the
call history and the message history reaches your database. Which is
Tracker I presume.

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.

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

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

oFono is not decided on how this reliable storage of history is done. It
is up to the history plugin. As said above, you might really need one
exactly for your specific needs.

I would be more than happy to be able to transfer this directly into
Tracker or Telepathy, but as outlined above that is not possible because
of the session vs system bus problem.

Regards

Marcel

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

[mikhail.zabaluev]

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

Hi,

> -----Original Message-----
> From: ofono-bounces(a)ofono.org [mailto:ofono-bounces(a)ofono.org] On
> Behalf Of ext Marcel Holtmann
> Sent: Wednesday, February 02, 2011 9:32 PM
> To: ofono(a)ofono.org
> Subject: RE: [RFC 2/2] doc: Add description for history agent interface
> 
> > > 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.
> 
> we are not delivering TPDUs to history, we are delivering messages.
> oFono will reassemble the segments for you. This is oFono's job.
> 
> 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.

> > 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.
> 
> oFono is running as system service. It can not interact directly with
> Tracker or Telepathy since both are only available on the session bus.
> 
> If you wanna activate some session bus based history service then that
> is out of the scope of oFono.
> 
> As I explained to Kai on IRC, I would personally not go via Telepathy
> since it is one extra (or even multiple) piece in the puzzle for the
> call history and the message history reaches your database. Which is
> Tracker I presume.

It's a solved piece in the puzzle. We do it for other protocols this way and are reasonably happy with it.
And sure, this is out of oFono scope.

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

> > 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.
> 
> oFono is not decided on how this reliable storage of history is done.
> It
> is up to the history plugin. As said above, you might really need one
> exactly for your specific needs.
> 
> I would be more than happy to be able to transfer this directly into
> Tracker or Telepathy, but as outlined above that is not possible
> because
> of the session vs system bus problem.

It is certainly possible, if the client is the one responsible for the final storage, and oFono simply keeps incoming SMSs until a client tells it to drop them.

Best regards,
  Mikhail

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

[Denis Kenzior]

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

Hi Mikhail,

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

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.

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

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? How many messages to spool? When to throw
away messages?  All of these issues are outside the scope of oFono.

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

Again, why do you say that? You can have N history plugins doing as much
or as little as you want.  You can have one for smshistory, one for call
history, etc.

Regards,
-Denis

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

[mikhail.zabaluev]

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

Hi,

> -----Original Message-----
> From: ext Denis Kenzior [mailto:denkenz(a)gmail.com]
> Sent: Thursday, February 03, 2011 6:12 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 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.

Best regards,
  Mikhail

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

[Marcel Holtmann]

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

Hi Mikhail,

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

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.

There should be only one piece of software that does handle SMS TPDU and
that piece of software is oFono. Everything else is insane since it is
guaranteed to fail. You do not wanna get involved in TPDU business from
any other piece of the software.

oFono does exactly what it needs, it spools message fragments. It does
not spool messages. Full messages spooling is up to the history plugin
if that is required.

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

And without using an agent you have no access control of who acks
messages. And additionally oFono does not store the read/unread states
either. oFono does not implement a message store.

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

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.

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

> > 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 or even acknowledge them.

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.

Regards

Marcel

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

[mikhail.zabaluev]

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

Hi Marcel,

> -----Original Message-----
> From: ofono-bounces(a)ofono.org [mailto:ofono-bounces(a)ofono.org] On
> Behalf Of ext Marcel Holtmann
> Sent: Friday, February 04, 2011 2:59 PM
> To: ofono(a)ofono.org
> Subject: RE: [RFC 2/2] doc: Add description for history agent interface
> 
> 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.

Best regards,
  Mikhail

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

[Denis Kenzior]

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

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

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

[mikhail.zabaluev]

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

Hi,

> -----Original Message-----
> From: ext Denis Kenzior [mailto:denkenz(a)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.

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

Best regards,
  Mikhail

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

[Marcel Holtmann]

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

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

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

You do have read my RFC patch, right? It does exactly this.

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

What has falling off the bus to do with this?

Regards

Marcel

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

[mikhail.zabaluev]

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

Hi,

> -----Original Message-----
> From: ofono-bounces(a)ofono.org [mailto:ofono-bounces(a)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?

> > > > 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?
> 
> You do have read my RFC patch, right? It does exactly this.

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

> > > 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.
> 
> What has falling off the bus to do with this?

If the whole setup is unreliable, advantages in performance are less pertinent.

Regards,
  Mikhail

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

[Denis Kenzior]

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

Hi Mikhail,

On 02/04/2011 12:52 PM, mikhail.zabaluev(a)nokia.com wrote:
> Hi,
> 
>> -----Original Message-----
>> From: ofono-bounces(a)ofono.org [mailto:ofono-bounces(a)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?
>

Because we wanted to avoid this exact discussion.  If you want some
particular API for text messaging, feel free to implement it.
Everything you need is provided.  The sms assembly / status assembly
code will not help you in any way here.

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

Then please take the hint and get more background first.  Marcel did
mention in the thread that his patch is an RFC (he is a maintainer after
all) and that spooling of messages when the agent is not registered is
still not done.

Regards,
-Denis

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

[Marcel Holtmann]

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

Hi Mikhail,

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

because oFono is NOT a message storage.

Every system will have a different message storage. We have history API
for abstracting the storage problem.

> > > > > 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?
> > 
> > You do have read my RFC patch, right? It does exactly this.
> 
> 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???

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?

> > > > 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.
> > 
> > What has falling off the bus to do with this?
> 
> If the whole setup is unreliable, advantages in performance are less pertinent.

There is nothing unreliable here from an oFono point of view. If your
agent crashes then that is the agent problem.

Regards

Marcel

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

[mikhail.zabaluev]

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

Hi,

> -----Original Message-----
> From: ofono-bounces(a)ofono.org [mailto:ofono-bounces(a)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?

When you receive a callback on NameOwnerChanged for the agent, the proposed patch, AFAICS, just nullifies the agent data in the history structure. Any history event handler called after that simply returns silently because the agent is not available.
This is a lousy failure mode, and you'll need to improve it. Presumably, by spooling whole messages until there is an agent ready to receive them.

Best regards,
  Mikhail

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

[Marcel Holtmann]

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

Hi Mikhail,

> > > 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?
> 
> When you receive a callback on NameOwnerChanged for the agent, the proposed patch, AFAICS, just nullifies the agent data in the history structure. Any history event handler called after that simply returns silently because the agent is not available.
> This is a lousy failure mode, and you'll need to improve it. Presumably, by spooling whole messages until there is an agent ready to receive them.

you do understand the concept of sending something as RFC, do you?

And I did clearly mentioned that the whole part of spooling call history
and message history when agent is not present is missing. That is a TODO
item and hence this was a RFC.

Regards

Marcel

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

[Denis Kenzior]

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

Hi Mikhail,

On 02/04/2011 12:07 PM, mikhail.zabaluev(a)nokia.com wrote:
> Hi,
> 
>> -----Original Message-----
>> From: ext Denis Kenzior [mailto:denkenz(a)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.
> 

I think you really need to go into the code and understand what is going
on there.  You have a misconception of how it works.  Trust me, the tpdu
fragment store does not translate to any sort of D-Bus API.  And once
you see the code, I'm sure you will be convinced not to even bother ;)

Moreover, you have to realize that there are non-text messages in that
tpdu store that go via an entirely different path and unless there's a
relevant plugin handling these, they will not go through history.

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.

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.)  That is how every single 'Agent' in oFono /
ConnMan / BlueZ works today anyway.

Regards,
-Denis

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

[mikhail.zabaluev]

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

Hi,

> -----Original Message-----
> From: ext Denis Kenzior [mailto:denkenz(a)gmail.com]
> Sent: Friday, February 04, 2011 8:27 PM
> To: Zabaluev Mikhail (Nokia-MS/Helsinki)
> Cc: ofono(a)ofono.org
> Subject: Re: [RFC 2/2] doc: Add description for history agent interface
> 
> Moreover, you have to realize that there are non-text messages in that
> tpdu store that go via an entirely different path and unless there's a
> relevant plugin handling these, they will not go through history.

The relevant consumers could pull those just as well...
But this is a good argument: with plugins there is no need for a "janitor" to purge messages that nobody knows what to do with. Also helps if we don't want unrelated consumers know about certain events.

> 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 :)

Best regards,
  Mikhail

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

[Marcel Holtmann]

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

Hi Mikhail,

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

So how many consumers of history events to you expect in a system. My
proposal limited this clearly to 1 and only 1. That was on purpose.

> > 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 :)

Let me repeat this. The oFono core is not a message spooling system or a
message storage. If spooling is needed it needs to be done in the
history plugin.

Regards

Marcel

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

[Denis Kenzior]

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

Hi Mikhail,

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

If you have multiple history agents going over D-Bus, that is your
problem ;)

>> 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 :)

Seriously, please go back to like, late 2009 archives on oFono and check
the history patches proposed back then.  You are seriously not adding
anything new to the discussion, just rehashing the same old arguments.
OBVIOUSLY you need to spool if you use a D-Bus based API, want
reliability and an agent is not connected.

But the assertion that the core has to perform the spooling is just
plain wrong.  There are cases when you do not need to spool, period
(e.g. well known filesystem store).  These are all details that are _out
of the scope_ of oFono and belong in the history plugin.

Regards,
-Denis

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

[Marcel Holtmann]

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

Hi Mikhail,

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

we are storing fragments reliable with a specific efficient way of doing
so. There is nothing generic about it.

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

So that are two D-Bus messages via AddMatch already.

> 2a. client calls ListMessages.
> 2b. oFono returns spooled messages.

These are already 4 D-Bus messages.

> If there are any messages, two more are needed:
> 
> 3a. client calls ExpungeMessages.
> 3b. oFono returns.

And another 2 for each message.

> When a new message is received:
> 
> 1. oFono emits a NewMessage signal.
> 2a. client calls ExpungeMessages.
> 2b. oFono returns.

These are another 3 per message.

And this does not include any status updates in case of submission
failed or delivery failed etc.

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

So your proposal is to make the messages available to everybody and then
put a security framework around it to not let everybody see and access
them. Instead of just controlling initial access to who gets the
messages by controlling access to the agent.

I go for the latter idea and controlling a single access point instead
of having to deal with multiple. Just good security principle.

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

Let me repeat. oFono does NOT implement a message store. We are storing
intermediate fragments if needed. That is different.

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

So if that is clear, why do we bother with the ACK thing again?

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

I still don't get why messages need to be explicitly represented and
acked. The agent just works fine and no race conditions. Spooled
messages can just replayed once the agent registers.

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

There is no waste inside oFono right now and there is not waste via the
history plugin. Right now I don't really know how much more clearer I
can explain this.

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

And other clients can do that as easily and way more reliable and with
more status information (like read/unread) via the message store. And
that is what you really wanna do anyway.

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

The basic security principle is to expose as less as possible. Think
about that for a bit.

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

I am getting a bit tired of explaining this over and over again. It is
not an unnecessary step. oFono is not a message store and it does not
store full messages for you. oFono works on fragments and fragments
alone.

Regards

Marcel

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

[mikhail.zabaluev]

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

Hi,

> -----Original Message-----
> From: ofono-bounces(a)ofono.org [mailto:ofono-bounces(a)ofono.org] On
> Behalf Of ext Marcel Holtmann
> Sent: Friday, February 04, 2011 7:15 PM
> To: ofono(a)ofono.org
> Subject: RE: [RFC 2/2] doc: Add description for history agent interface
> 
> > > 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.
> 
> So that are two D-Bus messages via AddMatch already.

There doesn't need to be a reply, but yeah, just in case dbus-daemon refuses.

> > 2a. client calls ListMessages.
> > 2b. oFono returns spooled messages.
> 
> These are already 4 D-Bus messages.

Right... but this is done once in the client's process lifetime.

> > If there are any messages, two more are needed:
> >
> > 3a. client calls ExpungeMessages.
> > 3b. oFono returns.
> 
> And another 2 for each message.

No, it's for the whole list of spooled messages.

> > When a new message is received:
> >
> > 1. oFono emits a NewMessage signal.
> > 2a. client calls ExpungeMessages.
> > 2b. oFono returns.
> 
> These are another 3 per message.
> 
> And this does not include any status updates in case of submission
> failed or delivery failed etc.

Um, that's for the outbound queue?
But those would be just signals; the plugin serves a full call roundtrip in these cases?

> > You do, it's controlled by the security framework in D-Bus.
> > Without checking security tokens, you cannot trust the agent, either.
> 
> So your proposal is to make the messages available to everybody and
> then
> put a security framework around it to not let everybody see and access
> them. Instead of just controlling initial access to who gets the
> messages by controlling access to the agent.

You mean, the first caller to register an agent gets inherent trust, no further access control needed?

> > > > > > 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.
> 
> So if that is clear, why do we bother with the ACK thing again?

Dennis asked about acking; I assumed he actually means who drives removal of messages from the spool.

> > > > > 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.
> 
> I still don't get why messages need to be explicitly represented and
> acked. The agent just works fine and no race conditions. Spooled
> messages can just replayed once the agent registers.

Hm, is it a push API that desperately wants to be an inverted pull API as well? :)

> The basic security principle is to expose as less as possible. Think
> about that for a bit.

I'd defer to the security framework in matters of security, not to race conditions in registering an agent.

Regards,
  Mikhail

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

[Kai.Vehmanen]

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

Hello Marcel,

On 02 Feb 2011, Marcel Holtmann wrote:
>> 	- 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.

my mistake. I got this impression from some recent discussion on
#ofono (related to the recent patches for TX spooling from Lucas 
De Marchi), and with that in mind, failed to look up what sms_assembly_add_fragment() 
really does in the end. I thought it was in-memory stuff only,
but oh no, commit 06ea6137a30944855ebafe0c8abfb2285eac74b5 
added fragment spooling (already in 2009!), so forget this part.

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

Ok. I just didn't see any mention of disk/file spooling in this
patchset (nor in other existing plugins except the out-of-tree
smshistory) one, and was not sure whether it is proposed to have
spooling before or after the DBus hop.

But yes, if indeed your intention was specifically to add spooling
to the ofono-side plugin already, I agree that would work.

Although, the plugin needs to store to disk _always_, even if agent 
is available. Or wait until the Dbus method reply is received (which
I don't think is feasible). Otherwise following can happen:
 
 - history_sms_received() called
 - agent available, MessageReceived() called not async so not
   waiting for reply
 - history_sms_received() returns to src/sms.c, TPUs cleared/acked
 -> zap, out of battery -> message potentially lost

This can be solved by spooling always.

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

Your plugin patch did not have/mention this functionality (message
goes to /dev/null if no agent is registered), but if this is
supposed to be there, then agreed, this'd work.
 
So I think this comes down to how the history agent acknowledges
the messages over DBus. E.g. single DBus MessageReceived method 
with ok/nok response, or an explicit acknowledge method/signal (the
StoredMessages telepathy implements the latter approach).

The main functional difference is the possibility to have
multiple agents (as Mikhail noted), but this is perhaps something
to debate whether it is really needed or not.

Otherwise, what I'm still not sure about is whether it's sane to 
have possibly very long req-reply roundtrips, and e.g. multiple pending 
calls of e.g. MessageReceived waiting for reply. I know it _can_ be 
done, but is it a robust design and will it cause grey hairs to agent 
implementors.. (I know many dbus bindings have default timeouts of 
roughly ~30s for method calls -> dunno if this can cause havoc). I freely 
admit my dbus skills/experience is not sufficient, so feedback is 
welcome.

Based on my very informal poll, more people have voted for
explicit acks in Telepathy style, but not all, so good arguments
for/against are welcome.

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

[Marcel Holtmann]

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

Hi Kai,

> >> - 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.
> 
> Ok. I just didn't see any mention of disk/file spooling in this
> patchset (nor in other existing plugins except the out-of-tree
> smshistory) one, and was not sure whether it is proposed to have
> spooling before or after the DBus hop.
> 
> But yes, if indeed your intention was specifically to add spooling
> to the ofono-side plugin already, I agree that would work.

I should have put a comment in the code to not confuse people ;)

> Although, the plugin needs to store to disk _always_, even if agent 
> is available. Or wait until the Dbus method reply is received (which
> I don't think is feasible). Otherwise following can happen:
>  
>  - history_sms_received() called
>  - agent available, MessageReceived() called not async so not
>    waiting for reply
>  - history_sms_received() returns to src/sms.c, TPUs cleared/acked
>  -> zap, out of battery -> message potentially lost
> 
> This can be solved by spooling always.

Yes, it needs to always spool.

But you did realize that we are doing this in oFono right already for
all things. You can zap the battery out and oFono will recover.

> >> 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.
> 
> Your plugin patch did not have/mention this functionality (message
> goes to /dev/null if no agent is registered), but if this is
> supposed to be there, then agreed, this'd work.
>  
> So I think this comes down to how the history agent acknowledges
> the messages over DBus. E.g. single DBus MessageReceived method 
> with ok/nok response, or an explicit acknowledge method/signal (the
> StoredMessages telepathy implements the latter approach).
> 
> The main functional difference is the possibility to have
> multiple agents (as Mikhail noted), but this is perhaps something
> to debate whether it is really needed or not.

Multiple agents is a bad idea. I am not allowing this on purpose. It is
also not really needed anyway. There should be one path and one path
only towards the database storage.

Per design oFono is not this database storage.

> Otherwise, what I'm still not sure about is whether it's sane to 
> have possibly very long req-reply roundtrips, and e.g. multiple pending 
> calls of e.g. MessageReceived waiting for reply. I know it _can_ be 
> done, but is it a robust design and will it cause grey hairs to agent 
> implementors.. (I know many dbus bindings have default timeouts of 
> roughly ~30s for method calls -> dunno if this can cause havoc). I freely 
> admit my dbus skills/experience is not sufficient, so feedback is 
> welcome.

If the D-Bus timeout will at any time become a problem then your whole
system is in deep trouble. You can just set a proper D-Bus timeout to
begin with including dbus-daemon -1 default which translates to some
large default timeout.

> Based on my very informal poll, more people have voted for
> explicit acks in Telepathy style, but not all, so good arguments
> for/against are welcome.

This is an explicit ACK via the agent. It is just a lot less D-Bus
message to achieve the same result.

Sorry, but Telepathy is pretty much wasteful with D-Bus message. So I am
pretty skeptic here and rather go with a sane approach that uses the
minium number of D-Bus messages and still receiving the same result.

Regards

Marcel