[commhistoryd] Fix sending MMS to multiple contacts. Contributes to JB#24418 #2
Conversation
| @@ -683,18 +683,22 @@ int MmsHandler::sendMessage(const QString &imsi, const QStringList &to, const QS | |||
| event.setStatus(Event::SendingStatus); | |||
| event.setIsRead(true); | |||
|
|
|||
| // XXX Group conversations not yet supported, so we will send one message at a time | |||
There was a problem hiding this comment.
Apart from that it will break the possibility (for others) to reply to the group on this message, and how it shows up there, can't this risk becoming very expensive if the user is charged per message?
Seems some charge per-recipient anyway, most being fixed-rate monthly of course, but hard to rule out conclusively.
There was a problem hiding this comment.
Currently, many tariffs have mms and sms packages from 300 to 1000 pieces, for which there is no charge for sending. I agree that these changes do not solve the multicast issue, but this functionality is not currently available.
There was a problem hiding this comment.
As long as the user is made aware, it is certainly better than nothing. 👍
There was a problem hiding this comment.
Currently, many tariffs have mms and sms packages from 300 to 1000 pieces, for which there is no charge for sending. I agree that these changes do not solve the multicast issue, but this functionality is not currently available.
mms-engine does support multiple recipients
There was a problem hiding this comment.
In the current reality, ShareMms has the ability to send mms to several contacts, but without this fix, no messages will be sent.
| @@ -683,18 +683,22 @@ int MmsHandler::sendMessage(const QString &imsi, const QStringList &to, const QS | |||
| event.setStatus(Event::SendingStatus); | |||
| event.setIsRead(true); | |||
|
|
|||
| // XXX Group conversations not yet supported, so we will send one message at a time | |||
| if (to.size() + cc.size() + bcc.size() > 1) { | |||
| QStringList recepients = to + cc + bcc; | |||
There was a problem hiding this comment.
This is wrong. To, cc and bcc lists are separate arguments and separate fields in the MMS message.
There was a problem hiding this comment.
@monich What's your idea of not using cc and bcc in recepients?
There was a problem hiding this comment.
I don't quite understand the question. org.nemomobile.MmsHandler.sendMessage (commhistoryd) receives them as separate lists so that they can be passed to org.nemomobile.MmsEngine.sendMessage (mms-engine) as separate lists, so that mms-engine can build a PDU where to, cc and bcc lists are separate lists.
The UI may or may not support building separate to, cc and bcc lists, but it's entirely a UX decision, for middleware it's a feature of the protocol, which middleware implements and provides to the UI.
Note that UI could call org.nemomobile.MmsEngine.sendMessage (mms-engine) directly and the message would be sent all right but it wouldn't be recorded in the commhistory database. The message goes through commhistoryd in order to record the message (and its attachments) in the database. IIRC multiple recipients were left unsupported because it wasn't clear how to represent multiple messages in the database in such a way that drafts, delivery reports, error handling etc. worked correctly.
Now...
Since after so many years it hasn't been implemented the right way (and MMS as a technology is slowly fading away), sending multiple copies of the same message doesn't look as such a bad idea anymore. It's definitely better than nothing, and anything better than that is unlikely to materialize. Two things though:
- Add a new D-Bus call (
org.nemomobile.MmsHandler.sendMessage2or another variant oforg.nemomobile.MmsHandler.sendMessage, whatever you like better) with a single list of recipients, attachments as file descriptors and a return value which allows the UI to tell what happened (e.g. all messages were sent, some or none, or whatever UI needs to handle send errors in a sane and useful way). Leave this D-Bus call as is, don't change its semantics. - Make sure that attachment files copied to commhistory storage are hard-linked, to avoid wasting storage space.
No description provided.