927716 - B2G SMS & MMS: sending functions need to eat parameters for requesting delivery report

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: RIL, defect)

Description

[Gene Lian (I already quit Mozilla)]

+++ This bug was initially created as a clone of Bug #919977 +++

Please see the user story at bug 919977. The AC 3 says:

  "AC 3: As a user I want to the per message basis configuration to override the default configuration."

To do this, the messaging APIs for sending SMS/MMS need to eat parameters for requesting delivery report per message basis. The proposed API changes will be:

partial interface nsIDOMMozMobileMessageManager
{
  jsval send(in jsval number, in DOMString message, boolean requestDeliveryReport);

  nsIDOMDOMRequest sendMMS(in jsval parameters, boolean requestDeliveryReport);
}

Comment 1

[Julien Wajsberg [:julienw]]

Maybe you can add this boolean in the parameters object instead for sendMMS ?

(same for in bug 927718)

For send, maybe it's a good time to use a parameters object too ?

Comment 2

[Gene Lian (I already quit Mozilla)]

(In reply to Julien Wajsberg [:julienw] from comment #1)
> Maybe you can add this boolean in the parameters object instead for sendMMS ?

IMO, what MmsParameters contains 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.

dictionary MmsParameters {
  sequence<DOMString> receivers;
  DOMString? subject = null;
  DOMString? smil = null;
  sequence<MmsAttachment> attachments;
};

dictionary MmsAttachment
{
  DOMString? id;
  DOMString? location;
  nsIDOMBlob content;
};

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

> 
> For send, maybe it's a good time to use a parameters object too ?

W3C still treats them separately for sending SMS [2]. Maybe it's fine for now.


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

Comment 3

[Julien Wajsberg [:julienw]]

That's because I dislike functions with lots of parameters, especially booleans...

How about one string parameter "report" then, that could have 4 different values:
* null
* "delivery"
* "read"
* "delivery-read"

Another idea: an array parameter, that could contains 2 delivery string values: "read" and "delivery" or be null.

Comment 4

[Gene Lian (I already quit Mozilla)]

Sounds like another nice alternative! Could you please put your comments to the WebAPI mailing list (title: Change Messaging API to Manage MMS Read Report for V1.3)? That would be nice if we could get W3C synchronized at the same time.

Comment 5

[Gene Lian (I already quit Mozilla)]

Please see bug 919977, comment #8 and bug 919977, comment #9. We don't hurry to support this for V1.3 but eventually we will.

Comment 6

[Joe Cheng [:jcheng] (please needinfo)]

blocking a committed 1.3 user story. 1.3+

Comment 7

[Joe Cheng [:jcheng] (please needinfo)]

revert the blocking flag per comment 5

Comment 8

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

Gene, I just set target milestone to 2/28.
Because this is blocking bug 919977 which is must-have before end of Feb.

Comment 9

[Julien Wajsberg [:julienw]]

That said, maybe it will be unprioritized because of the recent scheduling change.

Comment 10

[Gene Lian (I already quit Mozilla)]

Hi Wesley,

I'd like to pass this to Bevis since I already switched to the stream-3 team.

Hi Bevis,

I already had a road map in my mind. Please feel free to discuss with me if you face any difficulties. Thank you!

Comment 11

[Bevis Tseng[:bevis][:btseng](Exited)]

Hi Wesley,

Please help to confirm if this is still a blocker to 1.4 S2 (28feb).

Thanks

Comment 12

[Ken Chang[:kenkai]]

Put this bug into backlog.

Comment 13

[Bevis Tseng[:bevis][:btseng](Exited)]

no longer following up this bug.

Comment 14

[BMO Automation]

Firefox OS is not being worked on