The MMS lost story

jezek

Failed MMS redownload progress report:

This week these PR's got updated:

nuntium - send Received (uint - unix time) message parameter to telepathy-ofono, to ensure right place in message history. And Error (bool) and ErrorMessage (string) parameter got merged into one Error (string).
telepathy-ofono - on added message signal, fill message-received header with Received parameter (if found). Check and fill error message text from Error parameter.
history-service - no changes needed.
messaging-app - no changes, just rebased to xenial which changed upstream.
telephony-service - Just the MMS error text got truncated. Note: The PR wont build only for arm64 due to test fail. Seems not my fault, but needs to be fixed.

That's all this week. This projects is nearing it's end. If nothing goes wrong I'd say 2 weeks (without . documentation, tests and changelogs changes) and we are ready to test on dev, not only through ubports-qa.

Have a nice day.

jezek

Failed MMS redownload progress report:

This week I got rid of some TODOs in nuntium PR only.

@lduboeuf Can I ask you one more thing? Could you check (in messaging-app) if an error message is expired and if yes, don't allow to redownolad (hide the button and maybe change text). I'ts because I plan to delete and not listen to expired undownloaded messages in nuntium. And if the message is not listening in nuntium, then after clicking redownload in messaging-app, the message would be pending forever (until user deletes it). Thank you.

lduboeuf

@jezek Thanks for your weekly review of progress. I'm waiting it impatiently every Sunday evening

Good point for the expiry date, it needs to be done, will do it ASAP

lduboeuf

@jezek for the AutoRetrieve option, do you have already an idea what to do ?, or i can prepare if you want a setting callable from Dbus like for the MmmsEnabled here: https://github.com/ubports/nuntium/blob/0040206b63bd0a126e5242efa789a8201b7c5be0/cmd/nuntium/mediator.go#L447
I will need write access to Telephony-service PR though

let say "MmsAutoRetrieveEnabled" property name ?

Does the MMS notification message will have the same signature than a "cellular-off" one ?

jezek

@lduboeuf said in The MMS lost story:

@jezek for the AutoRetrieve option, do you have already an idea what to do ?, or i can prepare if you want a setting callable from Dbus like for the MmmsEnabled here: https://github.com/ubports/nuntium/blob/0040206b63bd0a126e5242efa789a8201b7c5be0/cmd/nuntium/mediator.go#L447
I will need write access to Telephony-service PR though

let say "MmsAutoRetrieveEnabled" property name ?

Does the MMS notification message will have the same signature than a "cellular-off" one ?

I haven't thought about it in such details yet. First, I would like to finish the failed mms issue. There are still some things to do. The MMS autoretrieval will be a separate project. So if you want to start ahead with the "MmsAutoRetrieveEnabled" setting (a good idea, the setting will be needed), just start a new draft (but I think it has time).

On another note. I thought to myself the other day, that it would be nice, if the messaging-app would show number of unread messages in icon, like teleports does.

lduboeuf

@jezek said in The MMS lost story:

@lduboeuf said in The MMS lost story:

@jezek for the AutoRetrieve option, do you have already an idea what to do ?, or i can prepare if you want a setting callable from Dbus like for the MmmsEnabled here: https://github.com/ubports/nuntium/blob/0040206b63bd0a126e5242efa789a8201b7c5be0/cmd/nuntium/mediator.go#L447
I will need write access to Telephony-service PR though

let say "MmsAutoRetrieveEnabled" property name ?

Does the MMS notification message will have the same signature than a "cellular-off" one ?

I haven't thought about it in such details yet. First, I would like to finish the failed mms issue. There are still some things to do. The MMS autoretrieval will be a separate project. So if you want to start ahead with the "MmsAutoRetrieveEnabled" setting (a good idea, the setting will be needed), just start a new draft (but I think it has time).

Yes, ok. I was first thinking to add a global setting ( like the MmsEnabled ) but i think that this flag should not be a user global setting, but related to the SIM account. Like MmsEnabled should also btw.
The thing is i don't know yet where it be defined...

On another note. I thought to myself the other day, that it would be nice, if the messaging-app would show number of unread messages in icon, like teleports does.

Yes, please add a feature request in messaging-app

jezek

If anybody installed nuntium PR since this weekend, please upgrade. I made mistake and nutium fails to acknowledge a successfully received multimedia message. Fortunately this error results in no data loss, just the MMS center will try to deliver your message more times. I'm sorry if I caused any inconvenience.

Keneda

@jezek
Only the one that never do anything never mistakes ^^

jezek

@lduboeuf said in The MMS lost story:

Yes, please add a feature request in messaging-app

Done here, but I don't know, how to flag it as feature request.

jezek

Failed MMS redownload progress report:

This week nuntium and messaging-app pull request drafts got update. @lduboeuf added code to messaging-app to not be able to initiate redownload of expired messages. And I fixed a bug in nuntium, wich I previously introduced. I've also made more work on nuntium localy, got rid of some TODOs, but I haven't fully tested the added code yet, so I'm not confident to push into PR draft right now. Will continue to work on this, see ya next time.

jezek

Failed MMS redownload progress report:

No commits to the drafts this week. Some work was done on nuntium locally, but like last week, it's not fully tested yet.

Keneda

@jezek said in The MMS lost story:

Don't be sad, we're not, take the time you need ^^

lduboeuf

@jezek no commits doesn't mean no progress. thank you for your months of efforts.

i'm already super happy with the feature as it is now, of course staying with 4 ubports-qa install is quite hazardous with devel updates but i can wait

jezek

Failed MMS redownload progress report:

This week I've been working on making nuntium message error handling more robust. That means, no message should be lost or unnoticed and if something really unexpected happens during incoming message handling (service problem, phone reboots, ...) message will try to recover or at least notify user during nuntium initialization. But today I've been mostly fixing errors I introduced during making nuntium more robust and found during testing, so I decided to not push new commits, until I test again (nuntium lacks unit tests, so I have to test manually).

I will report again, if when something changes.

Note: Most of my TODOs remaining in nuntium are about testing. If next tests don't uncover any errors, then only documentation. changelogs and a few unit tests are needed to be done and we can end the PR draft era and begin a review process.

AppLee

@jezek
Very good news.
Thank you so much for all the effort and trouble. Great contribution

jezek

Failed MMS redownload progress report:

Updated PR's:

nutium - Rebased to latest xenial + commits to make recovery of messages with unexpected errors during handling (phone/services crashes) more robust. The nuntium-inject-push tool was updated so it can simulate various errors. I've tried to test all possible error situations that came to my mind, found and fixed some flaws and I hope I didn't introduce any more errors. I will make more tests after I clear the last unsolved TODO (excluding testing & documentation TODOs) which was added by me.
messaging-app - Rebased to latest xenial.
telephony-service - Rebased to latest xenial (jekins still can't builf for armhf due to some test error which I think/hope is not my fault).

jezek

Failed MMS redownload progress report:

During cleanup I found a small issue. During nuntium initialization I start dbus listeners to listen to redownload or read/delete requests for messages in storage, but telepathy didn't spawn listeners for these. It's not a big issue, redownload still works, but read/delete requests from messaging-app don't come through to nuntium and that leads to polluted storage. I've tried to fix it, but today I broke something, so no new commits until I fix and test. I hope this is the last issue, that needs to be solved before reviews starts.

jezek

Failed MMS redownload progress report:

I've fixed the issue I found last week, but haven't tested it fully yet (so no commits). I will continue the cleanup, to start review process and inform you here on any progress.

jezek

Failed MMS redownload progress report:

This week only nuntium PR got updates. I've tested message handling and initialization and fixed some bugs I found. Then cleaned the code of my own TODO comments and debug logs. The documentation got updated to more reflect current state and some info that may be helpful was added.

The last thing (I hope) to do in nuntium PR is to update debian changelog, which brings me to a question about versioning.

The last version in changelog is 1.4+ubports1. This suggests, that the project has adopted semantic versioning system, which suggest to bump up major version if API backward compatibility is broken, bump up minor version if some new API is added, or bump up patch version otherwise. I've broken the API backward compatibility in the PR, so we should change the version to 2.0. But (there is always a but) I plan to make additional work on the nuntium project and there is a possibility, the API will change again. Therefore I suggest one of these:

Change version to 2.0 and if API changes in future bump to 3.0, etc.
Change version to 2.0, with some suffix that would suggest, that the API may change in near time (something like 2.0.0-alpha+ubportsX).
Rewrite changes that we can bump only the minor version to 1.5 (there is no way to not add to the API and preserve the minor version). This would take the most effort and even more to guarantee the same behavior for all API functions. I really don't want to walk down this path.
Don't bother with versioning, leave it as it is, nobody uses our nuntium packages.

I would vote for no. 2.

Note: I'm talking here about the nuntium go packages API (storage, telepathy, mms, ofono), The nuntium dbus API is backward compatible.

Side question: Where do you define the version?

Note: I'm really don't know who to ask these questions, so I add some names here, to attract attention. @lduboeuf @dobey @Flohack

flohack

@jezek So if I understand it right ubports1 was added since we are/were not the upstream for that project. Technically speaking you normally would not do such changes on the fork, and ubports1 can only be incremented to ubports2, whenever we add cosmetic patches etc.

But since we are probably now the upstream already, as Canonical dropped everything, we could remove the ubportsxy suffix and just bump to 2.0 as you explained. But please ask the developers in the Developer Telegram group, I am not heading the transition to 20.04 and some new rules might be in effect already.