Handling of SMS messages

[David Edmundson]

>
> Currently what the CM does is that all SMS messages are fetched from the
> SIM/Modem store upon the account going online,  marked as scrollback, and
> added as received messages.  And any new messages received via signals are
> subsequently added/displayed.
>
We can't really do this, it's way too much DBus traffic on connection,
every time.
It's a bit of a hack too.


> The rationale behind fetching all messages from the modem store everytime
> upon (the account) going online is :
> 1) To make the interface similar to (smart)phones wherein I can typically
> always see the  entire message threads between me and contacts. (Unlike say,
> FB or google chat where previous conversation history is not displayed in
> text-ui).
> 2) To ensure the CM always keeps track of all the messages, which is not
> possible by watching for the new message signals alone. For example, if the
> modem is plugged and connected to a different computer, or the SIM is
> switched between the modem and a phone, I might miss new messages if the CM
> don't scan all messages while connecting.
>
Is it? the SIM card stores if something is read or not, we need only
do this for new messages.

> But this has the following problem:
> Even though these messages fetched at connection time are marked as
> scrollback, KTp emits a notification (New message received..) even though
> these messages are just my old messages.

We /could/ solve that by modifying the approver to check the message
queue to see what type of message it is.
If they're all scrollback, ignore and close the channel.

>
> Even if we fix ktp to stop it from notifying us of scrollback messages (and
> just notify us of the genuinely new messages received): There's another
> problem. If there is a delay between the modem going online and the Tp
> account going online, we miss the signals for the new messages and instead
> they too get marked as scrollback. So we end up losing notifications for new
> messages received in this duration (between the modem and the Tp account
> going online).
>
> The alternative I see is to have some sort of message 'sync' routine when
> the modem goes online:
> 1)Scan all messages from the modem store when the account goes online.
> 2)Check if there are any new messages which are not there in the logger.
> Except for these 'new' messages, mark all others as scrollback (and we still
> need the fix to prevent notifications for scrollback messages).
> 3)Listen for signals for newer messages as usual.
>

There is another method.
It's a lot more complex, but I think a bit neater.

We recently introduced a clever system where logs can be fetched from
multiple sources, not just the TpLogger.

I propose (and I'd like Dan to verify this makes sense) we add our own
extra interface to your connection manager.

We can create our own custom channel interface
org.kde.Telepathy.Channel.Interface.Logs which can fetch and retrieve
logs.
we then make a logger backend that queries this new interface for messages.

Long term this is the most flexible (and ultimately sexy) solution as
it means we're only querying the logs on-demand.
Possibly overkill for just this SMS case, but as we make more CM's it
could be worth doing.

Thoughts?

David

> This is all assuming that we agree that displaying the entire message thread
> (history) in text-ui for SMS messages is the right way to go.
> Is there a better alternative?
>
> --
> Anant
>
> _______________________________________________
> KDE-Telepathy mailing list
> KDE-Telepathy at kde.org
> https://mail.kde.org/mailman/listinfo/kde-telepathy
>