-
Notifications
You must be signed in to change notification settings - Fork 7
Conversation
I'll take the review by this week. Thank you! |
Looks OK. |
Adds support for Read Reports (#84)
<li>in case the message has been read, with each of the items in the | ||
<code>readTimestamps</code> attribute set to the read time of | ||
the MMS message by the corresponding recipient, i.e. that in the | ||
same position of the <code>recipients</code> array. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just wondering one thing which might not related to this bug. So, the number of elements in the deliveryInfo array will correspond to the number of recipients array? If yes, why do we still need |MmsDeliveryInfo.recipient|? I originally thought that's why you want to add |recipient| for indexing and de-duplicating same duplicated recipients.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The number of elements in the deliveryInfo array will correspond to the amount of elements in the to, cc and bcc arrays unless there are duplicates. There are two reasons to keep MmsDeliveryInfo.recipient :
- Not having to deal with complex mapping between the recipients in to, cc and bcc and the elements in the deliveryInfo[] array
- de-duplicating recipients
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good! Mozilla will try to align the spec to this. Even if we don't have cc/bcc for now, we'd still have the duplication issue in the |receivers|.
No description provided.