Drafts messages for SMS and MMS

[Julien Wajsberg]

Hi,

we plan to implement draft messages for SMS and MMS in Firefox OS 1.3
(this is bug 879143).

The current spec in [2] references a "draft" state for both SMS and MMS
but does not define anything to save them.

Our current thought is to implement this in Gaia. The Mobile Messaging
API would only keep the received/send messages, but the draft behaviour
would be done in the Messages app (or whatever other Messages app we
could have in the future).

However I wanted to check with you before moving forward with this.

Thoughts ?

--
Julien

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=879143
[2] http://www.w3.org/2012/sysapps/messaging/

[janjo...@gmail.com]

+1

[Gene Lian]

Please see my in-line response.

----- Original Message -----
> From: "Julien Wajsberg" <jwaj...@mozilla.com>
> To: dev-w...@lists.mozilla.org
> Sent: Friday, September 20, 2013 10:03:05 PM
> Subject: Drafts messages for SMS and MMS
>
> Hi,
>
> we plan to implement draft messages for SMS and MMS in Firefox OS 1.3
> (this is bug 879143).
>
> The current spec in [2] references a "draft" state for both SMS and MMS
> but does not define anything to save them.

Indeed. I think the state "draft" proposed on W3C is totally infeasible because we don't have any APIs to save the drafts. Even if we have one, we still need to extend the current send() to be able to *resend* a draft that has already been saved in the DB. You can imagine how huge change we need to make APIs to deal with just drafting. Otherwise, the content side needs to retrieve the draft from DB, delete it from DB, and then call send() again to send the message as if sending a new one. In this case, the Gecko's DB just plays a role of general DB for saving drafts, then why should we maintain that DB in the back-end? Saving drafts in the front-end by indexedDB should be enough.

I'll fire a bug to W3C to address this issue later.

>
> Our current thought is to implement this in Gaia. The Mobile Messaging
> API would only keep the received/send messages, but the draft behaviour
> would be done in the Messages app (or whatever other Messages app we
> could have in the future).

Implementing drafting in Gaia makes much sense to me. Needless to say we're hoping to move the conversation thread DB from Gecko to Gaia in the long run. If the draft is also considered to be a valid message in the thread then we should stop to add it in the Gecko's DB. Eventually, the Gecko's DB will only deal with the received/sent messages that can be shared with multiple apps through the DataStore API.

>
> However I wanted to check with you before moving forward with this.
>
> Thoughts ?
>
> --
> Julien
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=879143
> [2] http://www.w3.org/2012/sysapps/messaging/
>
>

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
>

[Julien Wajsberg]

Thanks all, I see we all agree :)

[Gene Lian]

Fire a bug for this on W3C to strip out the 'draft' state:

https://github.com/sysapps/messaging/issues/83

Please leave comments if you have any other opinions. Thanks!

Gene

[Gene Lian]

Hi Guys,

MMS Read Report is going to be the new feature in the coming V1.3. To meet the timeline, we had better to start with the conversation earlier about the API change. The current API we have both in Mozilla and W3C is:

DOMRequest markMessageRead(in long id, in boolean value);

We originally thought the API implementation can directly be hooked up to a (new) setting value like "sendReadReport" to decide if it needs to return a read report to the requester, where the "sendReadReport" can be set through the Settings API. However, Ctai commented this approach would have at least 2 drawbacks:

1. Android phones in the field are capable of popping up a prompt to ask users "if you want to send read report for this message" when starting reading the message. If FFOS also wants to pop up such a prompt for *each* MMS, checking single setting value is not enough.

2. Third-party Messaging App might want to have a more flexible Messaging API to manage their own read report behaviours, instead of relying on the system settings and the Settings API.

Therefore, we hope to add an optional parameter in this API:

DOMRequest markMessageRead(in long id, in boolean value
[optional] in boolean sendReadReport);

When |value| == TRUE && |sendReadReport| == TRUE, it will send the read port back to the requester in addition to marking the message to be read in the DB. The default value could be FALSE.

Any thoughts are highly welcome. Thanks!

Gene

[EDUARDO FULLEA CARRERA]

Hi Gene,

Sounds good to me. Alternatively to having default value = FALSE we could keep the global setting that would apply if sendReadReport is not indicated. Just a thought.

> Any thoughts are highly welcome. Thanks!
>
> Gene

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

[Jonas Sicking]

On Sun, Sep 29, 2013 at 11:35 PM, Gene Lian <cl...@mozilla.com> wrote:
> Therefore, we hope to add an optional parameter in this API:
>
> DOMRequest markMessageRead(in long id, in boolean value
> [optional] in boolean sendReadReport);
>
> When |value| == TRUE && |sendReadReport| == TRUE, it will send the read port back to the requester in addition to marking the message to be read in the DB. The default value could be FALSE.

This sounds good to me.

/ Jonas

[Gene Lian]

Hi folks,

In addition to the markMessageRead(...) change, there is another key point that needs to be discussed as well. The issue is:

"How to expose the info of if an MMS has gotten read reports from receivers?"

After off-line discussions with Vicamo and Ctai, we proposed to add a new attribute |receiversRead| as below:

partial interface nsIDOMMozMmsMessage
{
...
readonly attribute jsval receivers; // DOMString[]
...
readonly attribute jsval receiversRead; // boolean[]
...
}

where each of the boolean values specifies if the MMS message has gotten the read report from the corresponding receiver in the |receivers| array.

Notes:

1. For incoming MMS, |receiversRead| will be null (non-applicable).
2. For outgoing MMS, the number of |receivers| and |receiversRead| arrays will be the same.

Does that sound reasonable to you guys? It seems W3C hasn't taken the MMS Read Report features into consideration so far [1]. Hope we can get feedback from Eduardo as well. :)

[1] http://messaging.sysapps.org/#idl-def-MmsMessage

Gene

[EDUARDO FULLEA CARRERA]

Hi Gene,

On 15 oct 2013 at 09:55:06, Gene Lian wrote:
> Hi folks,
>
> In addition to the markMessageRead(...) change, there is another key point that
> needs to be discussed as well. The issue is:
>
> "How to expose the info of if an MMS has gotten read reports from
> receivers?"
>
> After off-line discussions with Vicamo and Ctai, we proposed to add a new
> attribute |receiversRead| as below:
>
> partial interface nsIDOMMozMmsMessage
> {
> ...
> readonly attribute jsval receivers; // DOMString[]
> ...
> readonly attribute jsval receiversRead; // boolean[]
> ...
> }
> where each of the boolean values specifies if the MMS message has gotten the
> read report from the corresponding receiver in the |receivers| array.
>
> Notes:
>
> 1. For incoming MMS, |receiversRead| will be null (non-applicable).
> 2. For outgoing MMS, the number of |receivers| and |receiversRead| arrays
> will be the same.
>
> Does that sound reasonable to you guys? It seems W3C hasn't taken the MMS
> Read Report features into consideration so far [1]. Hope we can get feedback
> from Eduardo as well. :)
>

W3C has though taken into account the Delivery Status, which is a similar case. Although we initially had something similar to your proposal for the Delivery Status, we end up replacing it for something more elaborated, namely an attribute of MmsMessage called "deliveryInfo" [2] which is an array of MmsDeliveryInfo elements [3]. Each of these elements contains the recipient address, the delivery status and the delivery time. What is such structure solving over your proposal? :
-You can easily map the delivery status with each recipient, even if the API considers different types of recipients (To, Cc, Bcc), and even if any of the recipients eventually appears twice (e.g. in To and Cc), which is a corner case that was considered.
-The delivery time can be valuable information to expose.

From W3C perspective the easiest way to take the read status into account would be to extend the MmsDeliveryInfo element as follows (or create a new specific element):

dictionary MmsDeliveryInfo {
DOMString recipient;
DeliveryStatus deliveryStatus;
Date deliveryTimestamp;
ReadStatus readStatus;
Date readTimestamp;
};

enum ReadStatus {
"read",
"pending",
"error",
"not-applicable"
};

The question is, what do you think about how the delivery status is handled in W3C and whether it could be embraced in Firefox OS and extended to support read status?

[2] http://messaging.sysapps.org/#widl-MmsMessage-deliveryInfo
[3] http://messaging.sysapps.org/#idl-def-MmsDeliveryInfo

> [1] http://messaging.sysapps.org/#idl-def-MmsMessage
>
> Gene
>
> ----- Original Message -----
>> From: "Jonas Sicking" <jo...@sicking.cc> To: "Gene Lian"
>> <cl...@mozilla.com> Cc: "dev-webapi" <dev-w...@lists.mozilla.org>,
>> "Vicamo Yang" <vy...@mozilla.com>, "Julien Wajsberg"
>> <jwaj...@mozilla.com>, "EDUARDO FULLEA CARRERA" <e...@tid.es>,
>> "Chia-Hung Tai" <ct...@mozilla.com>, "Bevis Tseng" <bts...@mozilla.com>,
>> "Steve Chung" <sch...@mozilla.com> Sent: Friday, October 11, 2013
>> 8:55:51 AM Subject: Re: Change Messaging API to Manage MMS Read Report
>> for V1.3
>>
>> On Sun, Sep 29, 2013 at 11:35 PM, Gene Lian <cl...@mozilla.com> wrote:
>>> Therefore, we hope to add an optional parameter in this API:
>>>
>>> DOMRequest markMessageRead(in long id, in boolean value
>>> [optional] in boolean sendReadReport);
>>> When |value| == TRUE && |sendReadReport| == TRUE, it will send the
>>> read port back to the requester in addition to marking the message to
>>> be read in the DB. The default value could be FALSE.
>>
>> This sounds good to me.
>>
>> / Jonas
>>

[Gene Lian]

Thanks Eduardo for the feedback! Please see my in-line comments.

Yes! The way of you proposed for W3C spec looks good to me. Just two comments:

1. Does that sound better to use "success" than "read"? which is symmetric to the existing DeliveryStatus [1].
2. I think we should also add an extra set of onreadsuccess/onreadfailure just like ondeliverysuccess/ondeliveryfailure in MmsManager [2].

[1] http://messaging.sysapps.org/#idl-def-DeliveryStatus
[2] http://messaging.sysapps.org/#idl-def-MmsManager


Regarding the Mozilla spec, I think we'll change my original proposal based on your advice:

partial interface nsIDOMMozMmsMessage
{
...
readonly attribute jsval receivers; // DOMString[]
...

readonly attribute jsval deliveryStatus; // DOMString[]
...
readonly attribute jsval readStatus; // DOMString[] (new!)
...
}

where the readStatus is more symmetric to our existing deliveryStatus and the value can be "success"/"pending"/"error"/"not-applicable". We still treat them separately instead of using a structure to embrace them because I think it's easier to implement without breaking compatibility. Another reason is we haven't yet considered the cc/bcc features by far like W3C. In the future, we'll use a structure to access them when trying to align our spec to W3C and considering the compatibility issues at one time.

Also, we'll also add onreadsuccess/onreaderror as mentioned above:

partial interface nsIDOMMozMobileMessageManager : nsIDOMEventTarget
{
...
attribute jsval ondeliverysuccess;
attribute jsval ondeliveryerror;
attribute jsval onreadsuccess; (new!)
attribute jsval onreaderror; (new!)
};

What do you think?

Gene

[Gene Lian]

After more thoughts, we think it's nice to use a structure to encapsulate all the MMS delivery-related information since we're getting more and more attributes to be added. Treating them as different arrays sounds bad. We'll try to follow the W3C spec and coma back with a better proposal.

Gene

[EDUARDO FULLEA CARRERA]

Hi Gene,

On 16 oct 2013 at 18:17:31, Gene Lian wrote:
> Thanks Eduardo for the feedback! Please see my in-line comments.
>

> ----- Original Message -----
>> From: "EDUARDO FULLEA CARRERA" <e...@tid.es> To: "Gene Lian"
>> <cl...@mozilla.com>, "Jonas Sicking" <jo...@sicking.cc> Cc:

>> "dev-webapi" <dev-w...@lists.mozilla.org>, "Vicamo Yang"
>> <vy...@mozilla.com>, "Julien Wajsberg" <jwaj...@mozilla.com>,
>> "Chia-Hung Tai" <ct...@mozilla.com>, "Bevis Tseng" <bts...@mozilla.com>,

>> "Steve Chung" <sch...@mozilla.com> Sent: Tuesday, October 15, 2013

>> 4:59:49 PM Subject: RE: Change Messaging API to Manage MMS Read Report
>> for V1.3
>>

>> From W3C perspective the easiest way to take the read status into account
>> would be to extend the MmsDeliveryInfo element as follows (or create a new
>> specific element):
>>
>> dictionary MmsDeliveryInfo {
>> DOMString recipient;
>> DeliveryStatus deliveryStatus;
>> Date deliveryTimestamp;
>> ReadStatus readStatus;
>> Date readTimestamp;
>> };
>>
>> enum ReadStatus {
>> "read",
>> "pending",
>> "error",
>> "not-applicable"
>> };
>>
>> The question is, what do you think about how the delivery status is handled
>> in W3C and whether it could be embraced in Firefox OS and extended to
>> support read status?
>
> Yes! The way of you proposed for W3C spec looks good to me. Just two
> comments:
>
> 1. Does that sound better to use "success" than "read"? which is symmetric to
> the existing DeliveryStatus [1].

I initially thought 'read' would be more self-explanatory , but given your feedback I think 'success' is better for consistency with DeliveryStatus.

> 2. I think we should also add an extra set of onreadsuccess/onreadfailure just
> like ondeliverysuccess/ondeliveryfailure in MmsManager [2].
>

Right

> [1] http://messaging.sysapps.org/#idl-def-DeliveryStatus
> [2] http://messaging.sysapps.org/#idl-def-MmsManager
>
>

I have filed a bug [1] in SysApps to add support of Read Status

[1] https://github.com/sysapps/messaging/issues/84

Regards,
Eduardo.

[EDUARDO FULLEA CARRERA]

On 17 oct 2013 at 06:03:17, Gene Lian wrote:
>
> ----- Original Message -----

>> From: "Gene Lian" <cl...@mozilla.com> To: "EDUARDO FULLEA CARRERA"

>> <e...@tid.es> Cc: "Julien Wajsberg" <jwaj...@mozilla.com>, "Vicamo
>> Yang" <vy...@mozilla.com>, "dev-webapi" <dev-w...@lists.mozilla.org>,
>> "Chia-Hung Tai" <ct...@mozilla.com>, "Bevis Tseng" <bts...@mozilla.com>,

>> "Steve Chung" <sch...@mozilla.com>, "Jonas Sicking" <jo...@sicking.cc>

>> Sent: Thursday, October 17, 2013 12:17:31 AM Subject: Re: Change
>> Messaging API to Manage MMS Read Report for V1.3
>>

>> Regarding the Mozilla spec, I think we'll change my original proposal based
>> on your advice:
>>
>> partial interface nsIDOMMozMmsMessage
>> {
>> ...
>> readonly attribute jsval receivers; // DOMString[]
>> ...
>> readonly attribute jsval deliveryStatus; // DOMString[]
>> ...
>> readonly attribute jsval readStatus; // DOMString[] (new!)
>> ...
>> }
>> where the readStatus is more symmetric to our existing deliveryStatus
>> and the value can be "success"/"pending"/"error"/"not-applicable". We
>> still treat them separately instead of using a structure to embrace
>> them because I think it's easier to implement without breaking
>> compatibility. Another reason is we haven't yet considered the cc/bcc
>> features by far like W3C. In the future, we'll use a structure to
>> access them when trying to align our spec to W3C and considering the
>> compatibility issues at one time.
>
> After more thoughts, we think it's nice to use a structure to encapsulate all the
> MMS delivery-related information since we're getting more and more
> attributes to be added. Treating them as different arrays sounds bad. We'll try
> to follow the W3C spec and coma back with a better proposal.
>

The closer to the W3C the better, to avoid complex adaptations in the future. Keep me updated !

> Gene

[Gene Lian]

Thanks Eduardo for the sync!

We still have one (maybe last) requirement to change messaging API to support read report. Please see [1]. We hope to make:

partial interface nsIDOMMozMobileMessageManager
{
nsIDOMDOMRequest sendMMS(in jsval parameters, boolean requestReadReport);
}

which adds a new parameter |requestReadReport| so that the sender can request read report per message basis instead of relying on a general setting.

Another similar issue is for delivery report. Please see [2].

What do you think?

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=927718
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=927716

Gene

----- Original Message -----
> From: "EDUARDO FULLEA CARRERA" <e...@tid.es>
> To: "Gene Lian" <cl...@mozilla.com>

> Cc: "Jonas Sicking" <jo...@sicking.cc>, "dev-webapi" <dev-w...@lists.mozilla.org>, "Vicamo Yang"
> <vy...@mozilla.com>, "Julien Wajsberg" <jwaj...@mozilla.com>, "Chia-Hung Tai" <ct...@mozilla.com>, "Bevis Tseng"
> <bts...@mozilla.com>, "Steve Chung" <sch...@mozilla.com>

> Sent: Thursday, October 17, 2013 1:37:36 PM
> Subject: RE: Change Messaging API to Manage MMS Read Report for V1.3
>
> Hi Gene,
>
> On 16 oct 2013 at 18:17:31, Gene Lian wrote:
> > Thanks Eduardo for the feedback! Please see my in-line comments.
> >

> > ----- Original Message -----
> >> From: "EDUARDO FULLEA CARRERA" <e...@tid.es> To: "Gene Lian"
> >> <cl...@mozilla.com>, "Jonas Sicking" <jo...@sicking.cc> Cc:

> >> "dev-webapi" <dev-w...@lists.mozilla.org>, "Vicamo Yang"
> >> <vy...@mozilla.com>, "Julien Wajsberg" <jwaj...@mozilla.com>,
> >> "Chia-Hung Tai" <ct...@mozilla.com>, "Bevis Tseng" <bts...@mozilla.com>,

> >> "Steve Chung" <sch...@mozilla.com> Sent: Tuesday, October 15, 2013

> >> 4:59:49 PM Subject: RE: Change Messaging API to Manage MMS Read Report
> >> for V1.3
> >>

[Vicamo Yang]

Hi,

Can't we have that 'requestReadReport' be an attribute of 'jsval
parameters'?

--
Vicamo Yang 楊有勝
Mozilla Taiwan

[Gene Lian]

----- Original Message -----
> From: "Vicamo Yang" <vy...@mozilla.com>
> To: "Gene Lian" <cl...@mozilla.com>
> Cc: "EDUARDO FULLEA CARRERA" <e...@tid.es>, "Jonas Sicking" <jo...@sicking.cc>, "dev-webapi"
> <dev-w...@lists.mozilla.org>, "Julien Wajsberg" <jwaj...@mozilla.com>, "Chia-Hung Tai" <ct...@mozilla.com>,
> "Bevis Tseng" <bts...@mozilla.com>, "Steve Chung" <sch...@mozilla.com>
> Sent: Thursday, October 17, 2013 2:53:21 PM
> Subject: Re: Change Messaging API to Manage MMS Read Report for V1.3
>
> Hi,
>
> Can't we have that 'requestReadReport' be an attribute of 'jsval
> parameters'?

IMO, what the parameters contain is more like content but requestDeliveryReport is more like a setting to specify how to send the content. It sounds better to me to think of requestDeliveryReport as an API parameter.

W3C also thinks of the sending function in a similar way to send MMS content with a service ID [1].

[1] http://messaging.sysapps.org/#mmsmanager-interface

Gene

[EDUARDO FULLEA CARRERA]

Hi,

If we end up having two optional params 'requestDeliveryReport' and 'requestReadReport' plus the additional one we have in W3C ('serviceID') then we should include them in a dictionary.

Promise send (MmsContent mmsContent, optional MmsSendParams parameters);

dictionary MmsSendParams {
DOMString serviceID;
boolean requestDeliveryReport;
boolean requestReadReport;
};

How does it sound?

> Gene

[Julien Wajsberg]

Le 17/10/2013 10:27, EDUARDO FULLEA CARRERA a écrit :
> If we end up having two optional params 'requestDeliveryReport' and 'requestReadReport' plus the additional one we have in W3C ('serviceID') then we should include them in a dictionary.
>
> Promise send (MmsContent mmsContent, optional MmsSendParams parameters);
>
> dictionary MmsSendParams {
> DOMString serviceID;
> boolean requestDeliveryReport;
> boolean requestReadReport;
> };
>
> How does it sound?
>

I proposed something different to Gene.

I don't like booleans, they are difficult to read (although with a
dictionary it could be ok).

How about using strings instead ? I have 2 different proposals:

1. send (MmsContent mmsContent, String reports)

"reports" values can be:
* null, undefined: use the default
* "none": request no report
* "read": request read report
* "delivery": request delivery report
* "all": request all reports
* "read-delivery" or "delivery-read": request read and delivery reports
(currently same than "all" but could be different in the future)

2. send (MmsContent mmsContent, array reports)

"array" is an array of strings, strings can be "read" or "delivery" or
"all". "all" means ["read", "delivery"] currently, but may change in the
future.
An empty array means no report
null or undefined means "use default values"

--
Julien

[Vicamo Yang]

On 2013年10月17日 19:42, Julien Wajsberg wrote:
> Le 17/10/2013 10:27, EDUARDO FULLEA CARRERA a écrit :
>> If we end up having two optional params 'requestDeliveryReport' and 'requestReadReport' plus the additional one we have in W3C ('serviceID') then we should include them in a dictionary.
>>
>> Promise send (MmsContent mmsContent, optional MmsSendParams parameters);
>>
>> dictionary MmsSendParams {
>> DOMString serviceID;
>> boolean requestDeliveryReport;
>> boolean requestReadReport;
>> };
>>
>> How does it sound?

Sounds nice for me.

> I proposed something different to Gene.
>
> I don't like booleans, they are difficult to read (although with a
> dictionary it could be ok).
>
> How about using strings instead ? I have 2 different proposals:
>
> 1. send (MmsContent mmsContent, String reports)
>
> "reports" values can be:
> * null, undefined: use the default
> * "none": request no report
> * "read": request read report
> * "delivery": request delivery report
> * "all": request all reports
> * "read-delivery" or "delivery-read": request read and delivery reports
> (currently same than "all" but could be different in the future)
>
> 2. send (MmsContent mmsContent, array reports)
>
> "array" is an array of strings, strings can be "read" or "delivery" or
> "all". "all" means ["read", "delivery"] currently, but may change in the
> future.
> An empty array means no report
> null or undefined means "use default values"

There are other parameters like CC, BCC, MESSAGE-CLASS, etc. for
MmsContent and EXPIRY, DELIVERY-TIME, PRIORITY, SENDER-VISIBILITY, etc.
for MmsSendParams. So considering about the flexibility for new
attributes, the first proposal may end up with something like xfonts
config "*-true-*-blah-false-", which is really terrifying for me, and
the second one just makes no room for attributes other than reports.

[Julien Wajsberg]

yeah to me too ;)

> and the second one just makes no room for attributes other than reports.
>

Yep, the dictionary proposal is probably explicit enough thanks to the
property names.

--
Julien

[Gene Lian]

Sweet! Eventually, we're in agreement about the final API changes! Summarise all of them as below. Please let me know if you guys have any other opinions; otherwise, we'll implement the new API in this way. :)

-----
1. As a receiver, we want to return the read port to the sender per MMS basis:

partial interface nsIDOMMozMobileMessageManager
{
...
DOMRequest markMessageRead(in long id, in boolean value,
[optional] in boolean sendReadReport);
};

When |value| == TRUE && |sendReadReport| == TRUE, the back-end will send the read port back to the sender in addition to marking the message to be read in the DB. If |sendReadReport| is not indicated, use the general setting instead.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=921919

-----
2. As a sender, we want to specify and notify if an MMS has been read by a certain receiver:

partial interface nsIDOMMozMmsMessage
{
...
readonly attribute jsval receivers; // DOMString[]
...

readonly attribute jsval deliveryInfo; // MmsDeliveryInfo[]
...
};

dictionary MmsDeliveryInfo
{
DOMString receiver;
readonly attribute DOMString deliveryStatus;
readonly attribute DOMString readStatus;
};

Also, add 2 event handlers to notify the sender about the read event:

partial interface nsIDOMMozMobileMessageManager

{
...
attribute jsval ondeliverysuccess;
attribute jsval ondeliveryerror;
attribute jsval onreadsuccess;

attribute jsval onreaderror;
};

Bug #1: https://bugzilla.mozilla.org/show_bug.cgi?id=928821
Bug #2: https://bugzilla.mozilla.org/show_bug.cgi?id=921918

-----
3. As a sender, we want to request the delivery/read reports per MMS basis when sending it:

partial interface nsIDOMMozMobileMessageManager
{
...
DOMRequest sendMMS(in jsval parameters, /* MmsParameters */
in jsval sendParameters /* MmsSendParameters */);
};

dictionary MmsSendParameters
{
boolean requestDeliveryReport;
boolean requestReadReport;
};

If |requestDeliveryReport| or |requestReadReport| is not indicated, use the general setting instead.

Bug #1: https://bugzilla.mozilla.org/show_bug.cgi?id=927716
Bug #2: https://bugzilla.mozilla.org/show_bug.cgi?id=927718


Thanks,
Gene

[Gene Lian]

Alright, Ctai found we also need to add another flag. Add one more API change as below.

> 1. As a receiver, we want to return the read port to the sender per MMS
> basis:

Before returning the read report, Gaia has to know if it needs to pop up a prompt for it when receiving an MMS. Therefore, we need the following change as well:

partial interface nsIDOMMozMmsMessage
{
...
readonly attribute boolean isReadReportRequested;
...
};

The W3C should go the same. Eduardo, does that sound reasonable to you?

>
> partial interface nsIDOMMozMobileMessageManager
> {
> ...
> DOMRequest markMessageRead(in long id, in boolean value,
> [optional] in boolean sendReadReport);
> };
>
> When |value| == TRUE && |sendReadReport| == TRUE, the back-end will send the
> read port back to the sender in addition to marking the message to be read
> in the DB. If |sendReadReport| is not indicated, use the general setting
> instead.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=921919

Hope it's the last change we need. :)

Gene

[EDUARDO FULLEA CARRERA]

On 22 oct 2013 at 11:34:54, Gene Lian wrote:
> Alright, Ctai found we also need to add another flag. Add one more API change
> as below.
>
>> 1. As a receiver, we want to return the read port to the sender per MMS
>> basis:
>
> Before returning the read report, Gaia has to know if it needs to pop up a
> prompt for it when receiving an MMS. Therefore, we need the following
> change as well:
>
> partial interface nsIDOMMozMmsMessage
> {
> ...
> readonly attribute boolean isReadReportRequested;
> ...
> };
> The W3C should go the same. Eduardo, does that sound reasonable to you?

We can get this info without adding a new attribute just by looking at readStatus in MmsDeliveryInfo. In case its value equals "pending" then it means a read report was requested. The implementation should set that attribute to "pending" at sending time if the report was requested.

>
>>
>> partial interface nsIDOMMozMobileMessageManager
>> {
>> ...
>> DOMRequest markMessageRead(in long id, in boolean value,
>> [optional] in boolean sendReadReport);
>> };
>> When |value| == TRUE && |sendReadReport| == TRUE, the back-end will
>> send the read port back to the sender in addition to marking the
>> message to be read in the DB. If |sendReadReport| is not indicated, use
>> the general setting instead.
>>
>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=921919
>
> Hope it's the last change we need. :)
>
> Gene

[Gene Lian]

Thanks for the feedback! Please see the in-line.

----- Original Message -----
> From: "EDUARDO FULLEA CARRERA" <e...@tid.es>

It doesn't make sense to me.

The attribute we want to add is for the in-coming MMS. However, the MmsDeliveryInfo array is more for the out-going MMS. Do you want to use the same MmsDeliveryInfo.readStatus in a mixed way? If so, as a receiver, supposing the receivers array is ["123", "456", "789"], what do you expect about the content of the MmsDeliveryInfo array when it comes to the in-coming MMS? Is that a *single* element array like:

dictionary MmsDeliveryInfo {
DOMString recipient; // == "798" (user's phone number)
DeliveryStatus readStatus; // == "pending"
...
};

Or it has to be a multiple element array?

In any way, it sounds weird to me we have to index the element by a certain recipient to save a setting that should be applied to all the receivers. Also, the most important thing is, some phones doesn't provide MSISDN, which means the implementation cannot know which element's readStatus should be marked as "pending". IMO, since the request of read report comes along with the PDU spec, we should directly put it in the nsIDOMMozMmsMessage structure without any extra mapping.

[EDUARDO FULLEA CARRERA]

Hi Gene,

You are right, sorry for the confusion. Your proposal is fine for me.

I guess we don't need the equivalent attribute for delivery reports as they are supposed to be triggered promptly when the message is delivered instead of when the user interacts with it, and thus it does not make sense to ask the user on a per message basis, right?

[Gene Lian]

Hi Eduardo,

----- Original Message -----
> From: "EDUARDO FULLEA CARRERA" <e...@tid.es>
> To: "Gene Lian" <cl...@mozilla.com>
> Cc: "Chia-Hung Tai" <ct...@mozilla.com>, "Vicamo Yang" <vy...@mozilla.com>, "dev-webapi"
> <dev-w...@lists.mozilla.org>, "Bevis Tseng" <bts...@mozilla.com>, "Steve Chung" <sch...@mozilla.com>, "Shao-Hang
> Kao" <sk...@mozilla.com>, "Jonas Sicking" <jo...@sicking.cc>, "Julien Wajsberg" <jwaj...@mozilla.com>
> Sent: Tuesday, October 22, 2013 6:59:01 PM
> Subject: RE: Change Messaging API to Manage MMS Read Report for V1.3
>

> I guess we don't need the equivalent attribute for delivery reports as they
> are supposed to be triggered promptly when the message is delivered instead
> of when the user interacts with it, and thus it does not make sense to ask
> the user on a per message basis, right?

Correct! Delivery Report means whether an message has already been delivered/downloaded to user's device, so the system can internally handle it. Read Report somehow means the users have noticed/read the message by their eyes, so we need a UI to interact with it.

Gene

[Gene Lian]

Update the proposed APIs to summarise what we're going to make to support MMS Read Report eventually.

-----
1. As a receiver, we want to return the read port to the sender per MMS basis.

To do so, Gaia needs a way to know whether to pop up a prompt to request for the read report:

partial interface nsIDOMMozMmsMessage
{
...
readonly attribute boolean isReadReportRequested;
...
};

Later, the receiver can decide whether to send the read report back to the sender by:

partial interface nsIDOMMozMobileMessageManager
{
...
DOMRequest markMessageRead(in long id, in boolean value,
[optional] in boolean sendReadReport);
};

When |value| == TRUE && |sendReadReport| == TRUE, the back-end will send the read port back to the sender in addition to marking the message to be read in the DB. If |sendReadReport| is not indicated, use the general setting instead.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=921919

-----
2. As a sender, we want to specify and notify if an MMS has been read by a certain receiver:

partial interface nsIDOMMozMmsMessage
{
...

readonly attribute jsval receivers; // DOMString[]
...
readonly attribute jsval deliveryInfo; // MmsDeliveryInfo[]
...
};

dictionary MmsDeliveryInfo
{
DOMString receiver;
readonly attribute DOMString deliveryStatus;
readonly attribute DOMString readStatus;
};

Also, add 2 event handlers to notify the sender about the read report event:

partial interface nsIDOMMozMobileMessageManager
{
...
attribute jsval ondeliverysuccess;
attribute jsval ondeliveryerror;
attribute jsval onreadsuccess;
attribute jsval onreaderror;
};

Bug #1: https://bugzilla.mozilla.org/show_bug.cgi?id=928821
Bug #2: https://bugzilla.mozilla.org/show_bug.cgi?id=921918

-----

3. As a sender, we want to request for the delivery/read reports per MMS basis when sending it:

partial interface nsIDOMMozMobileMessageManager
{
...

DOMRequest sendMMS(in jsval parameters, /* MmsParameters */
in jsval sendParameters /* MmsSendParameters */);
};

dictionary MmsSendParameters
{
boolean requestDeliveryReport;
boolean requestReadReport;
};

If |requestDeliveryReport| or |requestReadReport| is not indicated, use the general setting instead.

Bug #1: https://bugzilla.mozilla.org/show_bug.cgi?id=927716
Bug #2: https://bugzilla.mozilla.org/show_bug.cgi?id=927718

Please let me know if you have any other opinions. Thanks!

Gene

[Jonas Sicking]

On Tue, Oct 22, 2013 at 7:32 AM, Gene Lian <cl...@mozilla.com> wrote:
> Update the proposed APIs to summarise what we're going to make to support MMS Read Report eventually.
>
> -----
> 1. As a receiver, we want to return the read port to the sender per MMS basis.
>
> To do so, Gaia needs a way to know whether to pop up a prompt to request for the read report:
>
> partial interface nsIDOMMozMmsMessage
> {
> ...
> readonly attribute boolean isReadReportRequested;
> ...
> };
>
> Later, the receiver can decide whether to send the read report back to the sender by:
>
> partial interface nsIDOMMozMobileMessageManager
> {
> ...
> DOMRequest markMessageRead(in long id, in boolean value,
> [optional] in boolean sendReadReport);
> };
>
> When |value| == TRUE && |sendReadReport| == TRUE, the back-end will send the read port back to the sender in addition to marking the message to be read in the DB. If |sendReadReport| is not indicated, use the general setting instead.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=921919

Sounds good to me. I suspect that the SMS app will want to know what
the "general setting" is, so it might be a good idea to expose that
through the MMS API somewhere. However maybe it's enough to expose it
through settings?

> 2. As a sender, we want to specify and notify if an MMS has been read by a certain receiver:
>
> partial interface nsIDOMMozMmsMessage
> {
> ...
> readonly attribute jsval receivers; // DOMString[]
> ...
> readonly attribute jsval deliveryInfo; // MmsDeliveryInfo[]
> ...
> };
>
> dictionary MmsDeliveryInfo
> {
> DOMString receiver;
> readonly attribute DOMString deliveryStatus;
> readonly attribute DOMString readStatus;
> };
>
> Also, add 2 event handlers to notify the sender about the read report event:
>
> partial interface nsIDOMMozMobileMessageManager
> {
> ...
> attribute jsval ondeliverysuccess;
> attribute jsval ondeliveryerror;
> attribute jsval onreadsuccess;
> attribute jsval onreaderror;
> };
>
> Bug #1: https://bugzilla.mozilla.org/show_bug.cgi?id=928821
> Bug #2: https://bugzilla.mozilla.org/show_bug.cgi?id=921918

When would "readerror" fire? I thought that either we'd get a
successful read report, in which case we would fire readsuccess, or we
wouldn't get anything?

> -----
> 3. As a sender, we want to request for the delivery/read reports per MMS basis when sending it:
>
> partial interface nsIDOMMozMobileMessageManager
> {
> ...
> DOMRequest sendMMS(in jsval parameters, /* MmsParameters */
> in jsval sendParameters /* MmsSendParameters */);
> };
>
> dictionary MmsSendParameters
> {
> boolean requestDeliveryReport;
> boolean requestReadReport;
> };
>
> If |requestDeliveryReport| or |requestReadReport| is not indicated, use the general setting instead.
>
> Bug #1: https://bugzilla.mozilla.org/show_bug.cgi?id=927716
> Bug #2: https://bugzilla.mozilla.org/show_bug.cgi?id=927718

Just add these two to the MmsParameters instead. And same comment as
above that it might be good to expose what the defaults are, but that
maybe settings API covers that.

/ Jonas

[EDUARDO FULLEA CARRERA]

The MMS standard supports sending a read report with value "Deleted without reading", which I am not sure if is used in practice. This would fire "readerror".

> . As a sender, we want to request for the delivery/read reports per MMS wrote on asis when sending it::

>> ...
>> DOMRequest sendMMS(in jsval parameters, /* MmsParameters */
>> in jsval sendParameters /* MmsSendParameters */);
>> };
>>
>> dictionary MmsSendParameters
>> {
>> boolean requestDeliveryReport;
>> boolean requestReadReport;
>> };
>> If |requestDeliveryReport| or |requestReadReport| is not indicated, use
>> the general setting instead.
>>
>> Bug #1: https://bugzilla.mozilla.org/show_bug.cgi?id=927716
>> Bug #2: https://bugzilla.mozilla.org/show_bug.cgi?id=927718
>
> Just add these two to the MmsParameters instead. And same comment as

We have discussed this earlier in this thread and reach the conclusion that at least for W3C Messaging API [1] these two fit better syntactically with serviceID as part of a new mmsSendParameters dictionary than as part of MmsContent.

[1] http://www.w3.org/2012/sysapps/messaging/#mmsmanager-interface

> above that it might be good to expose what the defaults are, but that
> maybe settings API covers that.
>
> / Jonas

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi

[Julien Wajsberg]

Le 22/10/2013 21:38, Jonas Sicking a écrit :
> On Tue, Oct 22, 2013 at 7:32 AM, Gene Lian <cl...@mozilla.com> wrote:
>> Update the proposed APIs to summarise what we're going to make to support MMS Read Report eventually.
>>
>> -----
>> 1. As a receiver, we want to return the read port to the sender per MMS basis.
>>
>> To do so, Gaia needs a way to know whether to pop up a prompt to request for the read report:
>>
>> partial interface nsIDOMMozMmsMessage
>> {
>> ...
>> readonly attribute boolean isReadReportRequested;
>> ...
>> };
>>
>> Later, the receiver can decide whether to send the read report back to the sender by:
>>
>> partial interface nsIDOMMozMobileMessageManager
>> {
>> ...
>> DOMRequest markMessageRead(in long id, in boolean value,
>> [optional] in boolean sendReadReport);
>> };
>>
>> When |value| == TRUE && |sendReadReport| == TRUE, the back-end will send the read port back to the sender in addition to marking the message to be read in the DB. If |sendReadReport| is not indicated, use the general setting instead.
>>
>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=921919
> Sounds good to me. I suspect that the SMS app will want to know what
> the "general setting" is, so it might be a good idea to expose that
> through the MMS API somewhere. However maybe it's enough to expose it
> through settings?
>

Actually, I now think we should not have a general setting, and rather
have the SMS app always provide this argument.

Or rather, we could have a general setting, but the app could read it
through the Settings API and use it when calling the Mobile Messaging
API. The Mobile Messaging API should not read this setting.

This would leave us free to implement how this settings is done, either
in the Settings API or in a local indexed DB.

--
Julien

[EDUARDO FULLEA CARRERA]

I have issued a Pull Request [1] to W3C Messaging API implementing the changes below. Please review and comment if needed.

[1] https://github.com/sysapps/messaging/pull/85

On 22 oct 2013 at 16:32:29, Gene Lian wrote:
> Update the proposed APIs to summarise what we're going to make to support
> MMS Read Report eventually.
>
> -----
> 1. As a receiver, we want to return the read port to the sender per MMS basis.
>
> To do so, Gaia needs a way to know whether to pop up a prompt to request for
> the read report:
>
> partial interface nsIDOMMozMmsMessage
> {
> ...
> readonly attribute boolean isReadReportRequested;
> ...
> };
> Later, the receiver can decide whether to send the read report back to the
> sender by:
>
> partial interface nsIDOMMozMobileMessageManager
> {
> ...
> DOMRequest markMessageRead(in long id, in boolean value,
> [optional] in boolean sendReadReport);
> };
> When |value| == TRUE && |sendReadReport| == TRUE, the back-end will send
> the read port back to the sender in addition to marking the message to be read
> in the DB. If |sendReadReport| is not indicated, use the general setting instead.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=921919
>

> -----

> 2. As a sender, we want to specify and notify if an MMS has been read by a
> certain receiver:
>

> partial interface nsIDOMMozMmsMessage
> {
> ...

> readonly attribute jsval receivers; // DOMString[]
> ...
> readonly attribute jsval deliveryInfo; // MmsDeliveryInfo[]
> ...
> };
>
> dictionary MmsDeliveryInfo
> {
> DOMString receiver;
> readonly attribute DOMString deliveryStatus;
> readonly attribute DOMString readStatus;
> };
> Also, add 2 event handlers to notify the sender about the read report event:
>
> partial interface nsIDOMMozMobileMessageManager
> {
> ...
> attribute jsval ondeliverysuccess;
> attribute jsval ondeliveryerror;
> attribute jsval onreadsuccess;
> attribute jsval onreaderror;
> };
> Bug #1: https://bugzilla.mozilla.org/show_bug.cgi?id=928821
> Bug #2: https://bugzilla.mozilla.org/show_bug.cgi?id=921918
>

> -----
> 3. As a sender, we want to request for the delivery/read reports per MMS basis
> when sending it:
>
> partial interface nsIDOMMozMobileMessageManager
> {
> ...

> DOMRequest sendMMS(in jsval parameters, /* MmsParameters */
> in jsval sendParameters /* MmsSendParameters */);
> };
>
> dictionary MmsSendParameters
> {
> boolean requestDeliveryReport;
> boolean requestReadReport;
> };

> If |requestDeliveryReport| or |requestReadReport| is not indicated, use the
> general setting instead.
>

> Bug #1: https://bugzilla.mozilla.org/show_bug.cgi?id=927716
> Bug #2: https://bugzilla.mozilla.org/show_bug.cgi?id=927718
>
>

> Please let me know if you have any other opinions. Thanks!
>
> Gene