Closed Bug 760065 (b2g-mms-dom-api) Opened 12 years ago Closed 6 years ago

[meta] WebMMS: Implement MMS DOM API

Categories

(Core :: DOM: Device Interfaces, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE
blocking-b2g -
blocking-basecamp -

People

(Reporter: ptseng, Assigned: vicamo)

References

Details

Attachments

(1 file, 39 obsolete files)

8.30 KB, text/plain
Details
In order to be compatible with old source codes, implement the MMS DOM in C++.
To begin with, duplicate the codes of SMS DOM and then rename "SMS" to "MMS". The MMS APIs temporarily remain unchanged, in other words, are identical to SMS APIs.
If certain a API of SMS and MMS conflicts, this API do nothing and just return in MMS DOM implementation.
We want to make sure this MMS DOM can work properly in a simplest way and then we can integrate real MMS features further...
Blocks: b2g-mms
Attached patch Create MMS DOM (obsolete) — Splinter Review
According the Description, create the MMS DOM
Source codes on github: https://github.com/PriceTseng/mozilla-central/tree/MMS-DOM
Attached patch Update MMS DOM (obsolete) — Splinter Review
(1) Replace the old MMS service
(2) Use the new nsIDOMMmsManager, nsIDOMMmsMessage and nsIDOMMmsAttachmentStorage interfaces

Source codes on github: https://github.com/PriceTseng/mozilla-central/tree/mms/dom-api/
Attached patch Part 1: add MmsManager (obsolete) — Splinter Review
1. fix permission
2. remove redundant package manifest entries
3. fix broken MOZ_WEBMMS_BACKEND guarding
4. fix "non-built-in class inherits built-in interface" error in nsIDOMMozMmsManager
5. remove all methods for now
6. remove redundant native implementation of MmsService in ril/
1. remove android code
2. remove SMS test code
3. remove GetNumberOfMessagesForText, which is only valid for SMS
Attachment #630099 - Attachment is obsolete: true
Attachment #632597 - Attachment is obsolete: true
Attached patch Part 2: add MmsMessage : WIP (obsolete) — Splinter Review
Attachment #634334 - Attachment is obsolete: true
Attached patch Part 2: add MmsMessage : WIP 2 (obsolete) — Splinter Review
1. add nsIDOMMmsAttachmentStorage.idl
2. MmsMessage.from should be DOMString
3. to, cc, bcc of MmsMessage need implicit_jscontext
4. implement accessors of from, recipients, to, cc, bcc, date of MmsMessage
5. define MmsMessageData

TODO: implement other accessors of MmsMessage
Attachment #634509 - Attachment is obsolete: true
Comment on attachment 634336 [details] [diff] [review]
Part 100: add MmsAttachmentStorage : WIP

also obsoleted by part 2
Attachment #634336 - Attachment is obsolete: true
Attachment #634510 - Attachment is obsolete: true
Attached patch [GAIA] Enable MMS for test : V2 (obsolete) — Splinter Review
test MozMmsMessage attributes
Attachment #634339 - Attachment is obsolete: true
Attached patch Part 2: add MmsMessage : WIP 3 (obsolete) — Splinter Review
sync interface definitions described in https://groups.google.com/d/msg/mozilla.dev.webapi/IuayswaeYO4/wmIQOa17Sv8J
Attachment #634849 - Attachment is obsolete: true
sync event interface definitions described in https://groups.google.com/d/msg/mozilla.dev.webapi/IuayswaeYO4/wmIQOa17Sv8J
Attachment #634850 - Attachment is obsolete: true
Attached patch Part 2: add MmsMessage : WIP 4 (obsolete) — Splinter Review
Support creating MozMmsMessage instance from MmsService. There is still one last thing to do: the attachment interface.
Attachment #635368 - Attachment is obsolete: true
Supports creating MmsDeliveryEventData from MmsService. Now event handling is completed and Gaia can be notified with correct event data.
Attachment #635371 - Attachment is obsolete: true
Attached patch [GAIA] Enable MMS for test : V3 (obsolete) — Splinter Review
add tests for MmsManager onreceived & ondelivered events.
Attachment #634853 - Attachment is obsolete: true
Attached patch Update MMS DOM (obsolete) — Splinter Review
Add the nsIDOMMmsAttchment interface

Source codes on github: https://github.com/PriceTseng/mozilla-central/tree/mms/dom-api/
blocking-basecamp: --- → ?
MMS is desired to be ready for basecamp, but does not actually block.
blocking-basecamp: ? → -
Attached patch Part 1: add MmsManager : V2 (obsolete) — Splinter Review
rebase
Attachment #634331 - Attachment is obsolete: true
Attached patch Part 2: add MmsMessage : WIP 5 (obsolete) — Splinter Review
Attachment #635659 - Attachment is obsolete: true
Attachment #635661 - Attachment is obsolete: true
Attachment #636239 - Attachment is obsolete: true
Depends on: 759427
Depends on: 773592
remove tab
Attachment #641335 - Attachment is obsolete: true
Use Date.getTime() instead of Date.valueOf()
Attachment #641336 - Attachment is obsolete: true
Attached patch Part 5: add MmsDatabaseService (obsolete) — Splinter Review
MmsDatabaseService is almost done now. Put/Get/event/... works fine. Change details are:

1. introduce nsIRilMmsDatabaseService.idl for internal method `saveMessage`
2. fix MmsManager::Delete return type
3. renew cid for MmsDatabaseService
4. move mms-received/sent notification into MmsDatabaseService
5. remove MmsDatabaseService.lasyKey, use auto_increment instead
6. remove `from`, `to` index from object store, add `recipients` as replacement
7. rename `date` index to `timestamp` in object store
8. remove file saving code from MmsTransactionService; store blobs into object store directly.
Attachment #641337 - Attachment is obsolete: true
There seems to be only one thing left unfinished: send interface.
Assignee: nobody → vyang
Attachment #634851 - Attachment is obsolete: true
Attached patch [GAIA] Enable MMS for test : V4 (obsolete) — Splinter Review
Attachment #635663 - Attachment is obsolete: true
Attached patch Part 1: add MmsManager : V3 (obsolete) — Splinter Review
Attachment #641333 - Attachment is obsolete: true
Attached patch Part 2: add MmsMessage : WIP 6 (obsolete) — Splinter Review
Attachment #641334 - Attachment is obsolete: true
Attachment #641829 - Attachment is obsolete: true
Attachment #641830 - Attachment is obsolete: true
Attachment #641835 - Attachment is obsolete: true
Attachment #641836 - Attachment is obsolete: true
Depends on: 798662
Blocks: 798664
Blocks: 798662
No longer depends on: 798662
Blocks: 799584
Blocks: 810099
Attached patch Part 1: IDL changes (obsolete) — Splinter Review
Attachment #641837 - Attachment is obsolete: true
Attachment #643331 - Attachment is obsolete: true
Attachment #643332 - Attachment is obsolete: true
Attachment #643333 - Attachment is obsolete: true
Attachment #643337 - Attachment is obsolete: true
Attachment #643338 - Attachment is obsolete: true
Attachment #643339 - Attachment is obsolete: true
Attachment #683656 - Flags: feedback?(kyle)
Comment on attachment 683656 [details] [diff] [review]
Part 1: IDL changes

Review of attachment 683656 [details] [diff] [review]:
-----------------------------------------------------------------

Had a meeting with Jonas Sicking today about the IDL posted here. In the interest of keeping things similar to SMS (since MMS and SMS messages will be threaded together in the messaging application), we'd like to not double up cursors, managers, etc... On top of that, it'd be nice if the interfaces matched each other enough that we could store MMS and SMS messages in the same database, use the same message thread building code, and basically keep all the work we've done to get messaging to where it is at the moment. 

I've attached a sketch of what we came up with. It's by no means complete, but gives a basic idea of what we're thinking about in order to make things similar enough to hopefully "just work". Would be great to get your feedback on if this is possible, as there is a lot of guesswork from our side since we aren't intimately familiar with the MMS spec or certification requirements yet.

We also had a few questions that came up while working on this:

- Where is the message content (SMIL) stored? Looks like there's only attachments for the MMSMessage type. Is content the first attachment?
- What does the "not-downloaded" status mean?
- Can cc/bcc be a single "receiver" list? I realize they're optional, and we haven't seen the use case doc yet.
- Where are attachment names denoted (for getAttachment from mmsAttachmentStorage)?
- What does the retrieve function on MMSMessage do?
- What does the applicationId property do?
Attachment #683656 - Flags: feedback?(kyle) → feedback-
Attachment #684240 - Attachment mime type: text/x-idl → text/plain
(In reply to Kyle Machulis [:kmachulis] [:qdot] from comment #39)
> We also had a few questions that came up while working on this:
> 
> - Where is the message content (SMIL) stored? Looks like there's only
> attachments for the MMSMessage type. Is content the first attachment?

It's not necessary to have a SMIL doc in a MMS message. For example, PIM objects, such as vCard and vCalendar can be sent without a presentation part(SMIL). For MMS messages without presentation parts(yes, there can be zero, one or multiple SMIL docs in one MMS message), we should still be able to render it.

> - What does the "not-downloaded" status mean?

MMS messages can be huge in comparison to SMS, so MMSC sends you a tiny notification containing necessary information to download the full message. In MANUAL/NEVER retrieval modes, the message has only incomplete headers and no attachments have been downloaded yet. Manual/Never retrieval modes are mandatory features.

> - Can cc/bcc be a single "receiver" list? I realize they're optional, and we
> haven't seen the use case doc yet.

See OMA-TS-MMS_ENC-V1_3-20110913-A, Appendix B.1.2
MMSE-C-021 "To Field"                                     Optional
MMSE-C-022 "Cc Field"                                     Optional
MMSE-C-023 "Bcc Field"                                    Optional
MMSE-C-024 "Support for at least one To, Cc or Bcc field" Mandatory

Yes, they're optional, even in ETS[1][2]. You can have "receivers" for now, and extend it to To, Cc, Bcc if "necessary". I mean, they're all defined in MMS standard, though optional, and most MMS clients supports them all.

> - Where are attachment names denoted (for getAttachment from
> mmsAttachmentStorage)?

The SMIL document has two ways to refer the presenting attachments. One through "Content-ID", another through "Content-Location". They are per part header fields. We can have something like:

  let partId = smilXml.partN.attributes["src"];
  let attachment = message.attachments[partId];

BTW, "name" and "filename" here are sub-parameters of per part header field "Content-Type". They're used as file names of the saved attachments.

> - What does the retrieve function on MMSMessage do?

In MANUAL/NEVER retrieval modes, a user may take the initiative to start the retrieval process. Again, MANUAL/NEVER retrieval modes are mandatory features.

> - What does the applicationId property do?

That's a optional feature defined in MMS-CONF[3] for VAS(Value Added Service) and other application control. We can ignore it for now. Note some MMS Proxy-Relay may reject messages without it, but I have no real world proof available yet.

[1]: see OMA-ETS-MMS_CON-V1_3-20101015-C section 5.6.1.6 "MMS-1.3-con-736 - Support for Cc field"
[2]: see OMA-ETS-MMS_CON-V1_3-20101015-C section 5.6.1.7 "MMS-1.3-con-737 - Support for Bcc field"
[3]: see OMA-TS-MMS-CONF-V1_3-20110913-A chapter 19 "Transporting Application Data"
Comment on attachment 684240 [details]
Sketch of possible MMS DOM API reusing+modifying SMS structures

Why not just:

  let msg = new MmsMessage();
  msg.to = [];
  msg.attachments["foo"] = new Blob();
  ...
  msg.send();

>dictionary MMSParams
>{
>  DOMString[] to; // Can we collapse these three into a single 'receivers' property? Will we have UI for separating to/cc/bcc?

I think we can. We have only a "receivers" attribute here, and by the time we decide cc/bcc fields are also mandatory, receivers can still be the super set of the three.

>  DOMString[] cc;
>  DOMString[] bcc;
>  DOMString subject;
>  MMSAttachment[] attachments;
>}
>
>dictionary MMSAttachment
>{
>  DOMString name;
>  DOMString? filename = null;
>  Blob content;
>}
>
>interface SmsMmsManager
>{
>  DOMRequest       send(DOMString number, MMSParams message);
>  DOMRequest       delete(in long id);                       // request.result == boolean
>  DOMRequest       markMessageRead(long id, boolean aValue); // request.result == boolean
>  DOMRequest       retreiveMMSMessage(in long id);

Why not moving the four APIs into MmsMessage? That makes more sense than tie everything on SmsMmsManager. And MMS has no "number".

>};
>
>interface MmsMessage
>{
>  ......
>  readonly attribute DOMString deliveryStatus; // Does this exist for MMS?

Yes, and since we have multiple receivers, there can also be multiple deliver statuses. See also OMA-Template-EnablerTestSpec-20040618-I section 5.4.1.4 "MMS-1.3-con-604 - Delivery report – Multiple recipients each with Different Delivery Status"

>  readonly attribute DOMString messageClass; // Does this exist for MMS?

Yes, MMS does, they are "Personal", "Advertisement", "Informational" or "Auto". But this is not a mandatory feature.

>  readonly attribute boolean   read;
>  readonly attribute DOMString body; // Should this be a different type?

I don't know the reason to have a body attribute here? Is this for SMIL?

>  readonly attribute MMSAttachment[] attachments;
>   
>  readonly attribute DOMString applicationId;

I think we can remove this for now.
Based on discussion with Jonas today. Changes are:

* MMSParams
1. remove to/cc/bcc, add receivers
2. subject is a mandatory feature but an optional field in MMS PDU.
3. add a smil attribute

* SMSParams
1. added to sync interface of MMS
2. use singular receiver instead

* MMSAttachment
1. name parameter is optional(?)
2. add contentId and contentLocation for referring media objects in SMIL

* SmsMmsManager
1. use sendSMS(SMSParams) as well
2. no additional "number" parameter in sendMMS

* MmsMessage
1. remove messageClass
2. MMS has multiple deliveryStatus
3. rename body to smil
4. remove applicationId

* SmsMmsFilter
1. rename numbers to receivers to sync terminology
2. rename status to state for the same reason
Attachment #683656 - Attachment is obsolete: true
Attachment #684240 - Attachment is obsolete: true
Attachment #684381 - Flags: feedback?(kyle)
Attachment #684381 - Flags: feedback?(jonas)
(In reply to Vicamo Yang [:vicamo][:vyang] from comment #43)
> Created attachment 684381 [details]
> Sketch of possible MMS DOM API reusing+modifying SMS structures : v2

One question just comes to my mind, what happens if retrieveMMS() fails? What's the message state then?
I would imagine it should remain "not-downloaded"
(In reply to Jonas Sicking (:sicking) from comment #45)
> I would imagine it should remain "not-downloaded"

What if it's some permanent error like "expired"?
Good question. Maybe use a separate state when download fails for a permanent reason. So something like "expired"?
Comment on attachment 684381 [details]
Sketch of possible MMS DOM API reusing+modifying SMS structures : v2

Looks great!

>interface SmsMessage
>{
>  readonly attribute long      type; // "sms"

This should be of type DOMString, right?

>  readonly attribute long      id;
>  readonly attribute DOMString state; // "received", "sending", "sent", "error"
>  readonly attribute DOMString sender;
>  readonly attribute DOMString receiver;
>  readonly attribute Date      timestamp;
>  readonly attribute DOMString deliveryStatus;
>  readonly attribute DOMString messageClass;
>  readonly attribute boolean   read;
>
>  readonly attribute DOMString body;
>};
> 
>interface MmsMessage
>{
>  readonly attribute long      type; // "mms"

Same here.

>  readonly attribute long      id;
>  readonly attribute DOMString state; // "not-downloaded", "received", "sending", "sent", "error"

So add "expired" here or some such?
Attachment #684381 - Flags: feedback?(jonas) → feedback+
Attachment #684381 - Flags: feedback?(kyle) → feedback+
Comment on attachment 684381 [details]
Sketch of possible MMS DOM API reusing+modifying SMS structures : v2

>dictionary SmsMmsFilter {
>  Date        startDate;
>  Date        endDate;
>  DOMString[] receivers;
>  DOMString   state; // "sent","received", "error", "sending", "not-downloaded"
>  DOMString   type; // "sms","mms"
>  boolean     read;
>};

One question regarding the usage of filter, which can support me to implement the MMS database (bug 811252). The following shows the database schema:

    let objectStore = aDb.createObjectStore(MMS_STORE_NAME, { keyPath: "id" });
    objectStore.createIndex("timestamp",      "timestamp",      { unique: false });
    objectStore.createIndex("sender",         "sender",         { unique: false });
    objectStore.createIndex("receivers",      "receivers",      { unique: false });
    objectStore.createIndex("deliveryStatus", "deliveryStatus", { unique: false });
    objectStore.createIndex("state",          "state",          { unique: false });
    objectStore.createIndex("read",           "read",           { unique: false });
    objectStore.createIndex("smil",           "smil",           { unique: false });
    objectStore.createIndex("attachments",    "attachments",    { unique: false });

where the |receivers| is an array of strings. Supposing the |SmsMmsFilter.receivers| is:

  SmsMmsFilter.receivers = ["John", "Bob", "Tom"]

and we have 3 database records that have their own |receivers| as below:

  1. db.receivers = ["John", "Bob", "Tom"]
  2. db.receivers = ["John", "Bob"]
  3. db.receivers = ["John", "Bob", "Marry"]

Which ones should be matched and which ones shouldn't be?
Comment on attachment 684381 [details]
Sketch of possible MMS DOM API reusing+modifying SMS structures : v2

I am trying to align the Messaging API proposal to W3C with the latest status of SMS/MMS API and have the following questions/comments:

>dictionary MMSParams
>{
>  DOMString[] receivers;

"recipients" seems a better wording that "reciever" in the messaging jargon 

>  DOMString? subject = null;
>  DOMString? smil = null;
>  MMSAttachment[] attachments;
>}
>
>dictionary SMSParams
>{
>    DOMString receiver;

same here

>    DOMString text;
>}
>
>dictionary MMSAttachment
>{
>  DOMString? name = null;
>  DOMString? filename = null;
>  DOMString? contentId = null;
>  DOMString? contentLocation = null;
>  Blob content;
>}

Do we need the four "name", "filename", "contentId" and "contentLocation" elements? I understand "contentId" and "contentLocation" are used to refer to elements from the smil, being the first mandatory and the second optional. What are really "name" and "filename" meant for?

On the other hand I see the way to access the attachments has changed wrt to the API in the wiki (https://wiki.mozilla.org/WebAPI/WebMMS). The one in this proposal, using arrays, seems not to be as simple as the one in the wiki. Could you explain the reasons for this change?

>
>interface SmsMmsManager
>{
>  DOMRequest       sendSMS(SMSParams message);

It would be useful to allow sending 'n' SMS messages to 'n' different recipients in a single call. Any reason for not allowing it?

>  DOMRequest       sendMMS(MMSParams message);
>  unsigned short   getNumberOfSMSMessagesForText(in DOMString text);

getNumberOfSMSMessagesForText is a quite confusing name. In the W3C proposal I am using 'numberOfSmsSegments' which IMO is more clear.

>  DOMRequest       delete(in long id);                       // request.result == boolean

It would be interesting to delete multiple messages in a single call.

>  DOMRequest       getMessage(in long id);                   // request.result == SMSMessage/MMSMessage
>  DOMRequest       getMessages(in SmsMmsFilter filter, bool reverse); // request.result == SMSMMSIterator
>  DOMRequest       markMessageRead(long id, boolean aValue); // request.result == boolean

It would be interesting to mark multiple messages as read in a single call.

>  DOMRequest       retreiveMMSMessage(in long id);
>};
>
>interface SmsMessage
>{
>  readonly attribute long      type; // "sms"

Do we really need the 'type' attribute provided that we have different types for SMS and MMS?

>  readonly attribute long      id;
>  readonly attribute DOMString state; // "received", "sending", "sent", "error"
>  readonly attribute DOMString sender;
>  readonly attribute DOMString receiver;
>  readonly attribute Date      timestamp;
>  readonly attribute DOMString deliveryStatus;
>  readonly attribute DOMString messageClass;
>  readonly attribute boolean   read;
>
>  readonly attribute DOMString body;

It may be good to change 'body' into 'text' to align with SMSParams

>};
> 
>interface MmsMessage
>{
>  readonly attribute long      type; // "mms"
>  readonly attribute long      id;
>  readonly attribute DOMString state; // "not-downloaded", "received", "sending", "sent", "error"
>  readonly attribute DOMString sender;
>  readonly attribute DOMString[] receivers;
>  readonly attribute Date      timestamp;
>  readonly attribute DOMString[] deliveryStatus;

What values can deliveryStatus have?

>  readonly attribute boolean   read;
>   
>  readonly attribute DOMString smil;
>  readonly attribute MMSAttachment[] attachments;
>}

'subject' is missing

It may be useful to have an interface (called for instance MobileMessage) that includes the common elements between SmsMessage and MmsMessage, from which this two inherit. For instance if we have a single iterator, which BTW has not been defined in the proposal, that returns a MobileMessage (actually an SmsMessage or an MmsMessage).

>
>dictionary SmsMmsFilter {
>  Date        startDate;
>  Date        endDate;
>  DOMString[] receivers;

We should be able to search also by the sender of the message. Let's add DOMString sender;

>  DOMString   state; // "sent","received", "error", "sending", "not-downloaded"
>  DOMString   type; // "sms","mms"
>  boolean     read;
>};
(In reply to Eduardo Fullea from comment #50)
> >    DOMString text;
> >}
> >
> >dictionary MMSAttachment
> >{
> >  DOMString? name = null;
> >  DOMString? filename = null;
> >  DOMString? contentId = null;
> >  DOMString? contentLocation = null;
> >  Blob content;
> >}
> 
> Do we need the four "name", "filename", "contentId" and "contentLocation"
> elements? I understand "contentId" and "contentLocation" are used to refer
> to elements from the smil, being the first mandatory and the second
> optional. What are really "name" and "filename" meant for?

I think one of them is used if the user wants to save the file. Then this is the recommended filename to use. But I'm not sure.

Vicamo?

> On the other hand I see the way to access the attachments has changed wrt to
> the API in the wiki (https://wiki.mozilla.org/WebAPI/WebMMS). The one in
> this proposal, using arrays, seems not to be as simple as the one in the
> wiki. Could you explain the reasons for this change?

While the one in the wiki has more functionality, the one here is definitely a "simpler" API in that it's a smaller API.

Iterating an array and finding the file with a specific id is very easy to do in javascript. And it means that we don't have to create a bunch of functions for getting and setting metadata for the various files.

I think smaller is better here. The amount of code saved by authors is just one or two lines of JS and it makes the API easier to understand.

> >  DOMRequest       sendMMS(MMSParams message);
> >  unsigned short   getNumberOfSMSMessagesForText(in DOMString text);
> 
> getNumberOfSMSMessagesForText is a quite confusing name. In the W3C proposal
> I am using 'numberOfSmsSegments' which IMO is more clear.

Actually, this function has changed in bug 820780.

getSegmentInfoForSMS or segmentInfoForSMS seems appropriate.

> >  DOMRequest       delete(in long id);                       // request.result == boolean
> 
> It would be interesting to delete multiple messages in a single call.

Unless we can show that there are performance benefits, I don't think we need to add syntax sugar for sending/deleting/marking-read multiple messages at the same time.

> >interface SmsMessage
> >{
> >  readonly attribute long      type; // "sms"
> 
> Do we really need the 'type' attribute provided that we have different types
> for SMS and MMS?

JS is unfortunately not very good at checking the type of an object. The 'instanceof' operator doesn't work well when there are multiple globals involved which often happens in advanced web pages.

> >  readonly attribute DOMString body;
> 
> It may be good to change 'body' into 'text' to align with SMSParams

The body can contain much more than text for MMS though. It'll include timing information and how to compose the various attachments as well.


> It may be useful to have an interface (called for instance MobileMessage)
> that includes the common elements between SmsMessage and MmsMessage, from
> which this two inherit. For instance if we have a single iterator, which BTW
> has not been defined in the proposal, that returns a MobileMessage (actually
> an SmsMessage or an MmsMessage).

There's not really a reason to do that in javascript since it's dynamically typed. If you just make the iterator return "Object"s then that will look exactly the same to the webpage.

Creating complex interface heirarchies makes sense in languages like Java, but it doesn't really as much in Javascript. (This was a mistake that the original DOM authors did, and which has been carried forward since unfortunately).
(In reply to Jonas Sicking (:sicking) from comment #51)

> > On the other hand I see the way to access the attachments has changed wrt to
> > the API in the wiki (https://wiki.mozilla.org/WebAPI/WebMMS). The one in
> > this proposal, using arrays, seems not to be as simple as the one in the
> > wiki. Could you explain the reasons for this change?
> 
> While the one in the wiki has more functionality, the one here is definitely
> a "simpler" API in that it's a smaller API.
> 
> Iterating an array and finding the file with a specific id is very easy to
> do in javascript. And it means that we don't have to create a bunch of
> functions for getting and setting metadata for the various files.
> 

Yes, but in order to get an specific attachment with a certain name the developer would need to iterate over all the elements attachments array. My counterproposal is to change the attachments array by an attachments dictionary that will be indexed by attachment name. In that case if someone wants to iterate over all the attachments could do it by using the 

Object.keys(attachment).forEach and on the other hand it would be direct to get random access to attachments by using attachments[myAttachmentName]

> I think smaller is better here. The amount of code saved by authors is just
> one or two lines of JS and it makes the API easier to understand.
> 

> Creating complex interface heirarchies makes sense in languages like Java,
> but it doesn't really as much in Javascript. (This was a mistake that the
> original DOM authors did, and which has been carried forward since
> unfortunately).

ok.
No longer blocks: 804679
(In reply to Jonas Sicking (:sicking) from comment #51)
> (In reply to Eduardo Fullea from comment #50)

> > It would be interesting to delete multiple messages in a single call.
> 
> Unless we can show that there are performance benefits, I don't think we
> need to add syntax sugar for sending/deleting/marking-read multiple messages
> at the same time.
> 

It seems to be a real need from the developers of the messaging app. Perhaps Borja can ellaborate on this point.

> > Do we really need the 'type' attribute provided that we have different types
> > for SMS and MMS?
> 
> JS is unfortunately not very good at checking the type of an object. The
> 'instanceof' operator doesn't work well when there are multiple globals
> involved which often happens in advanced web pages.

OK, thanks for the clarification.
 
> > >  readonly attribute DOMString body;
> > 
> > It may be good to change 'body' into 'text' to align with SMSParams
> 
> The body can contain much more than text for MMS though. It'll include
> timing information and how to compose the various attachments as well.
> 

'body' is currently an attribute of the SmsMessage interface, not of the MmsMessage one.

> 
> > It may be useful to have an interface (called for instance MobileMessage)
> > that includes the common elements between SmsMessage and MmsMessage, from
> > which this two inherit. For instance if we have a single iterator, which BTW
> > has not been defined in the proposal, that returns a MobileMessage (actually
> > an SmsMessage or an MmsMessage).
> 
> There's not really a reason to do that in javascript since it's dynamically
> typed. If you just make the iterator return "Object"s then that will look
> exactly the same to the webpage.
> 
> Creating complex interface heirarchies makes sense in languages like Java,
> but it doesn't really as much in Javascript. (This was a mistake that the
> original DOM authors did, and which has been carried forward since
> unfortunately).

Understood
Blocks: 838000
Blocks: 838002
Blocks: 838003
Blocks: 840040
Blocks: 840044
Blocks: 840047
Blocks: 840049
Blocks: 840053
Blocks: 840054
Blocks: 840055
Blocks: 840056
Blocks: 840057
Blocks: 840058
Blocks: 840059
Blocks: 840065
Blocks: 840068
Blocks: 840069
Blocks: 840075
Blocks: 840082
Blocks: 840085
Blocks: 840087
Blocks: 840090
blocking-b2g: --- → leo?
Blocking- because metabug. Please nominate the bugs that have the actual work.
blocking-b2g: leo? → -
Blocks: 844054
Depends on: 839436
Summary: B2G MMS: Implement MMS DOM API → [meta] B2G MMS: Implement MMS DOM API
I'll update all the DOM API spec tomorrow based on our previous discussions offline. Please stay tuned.
No longer blocks: 843445
Depends on: 843445
No longer depends on: 849742
No longer depends on: 852863
Attached file Sketch of Mobile Message DOM API, V3 (obsolete) —
Attachment #730618 - Flags: feedback?(mounir)
Attachment #730618 - Flags: feedback?(jonas)
Attachment #684381 - Attachment is obsolete: true
Comment on attachment 730618 [details]
Sketch of Mobile Message DOM API, V3

I tried to summarize up the DOM API based on our on-line discussion, off-line discussion, what we've already implemented or still under way. I believe this update can provide a more clear road map and guide the clients how to use them correctly. Please take a look if you have any other suggestions or comments. Thanks!
Attachment #730618 - Attachment mime type: text/x-idl → text/plain
Attachment #730618 - Flags: feedback?(vyang)
Comment on attachment 730618 [details]
Sketch of Mobile Message DOM API, V3

Thanks for doing that Gene :) Could you send this my email to Eduardo Fuella Carrera (from Telefonica) (CC the persons you asked for feedback in this bug). Eduardo is taking care of the Messaging API at the W3C. I am pretty sure he will be very interested by that document.

As I see it, the next steps for the API work related to SMS and MMS should happen at the W3C. Whilst the specification is being worked on in the working group, we should feel free to evolve our API the way we see fit the requirements we have but we should make sure that anything we want to have in the final design gets upstreamed to the SysApps WG. It goes without saying that the working group is open to anyone who wants to participate. I'm going to send an email at dev-webapi today about this.
Attachment #730618 - Flags: feedback?(mounir)
Attached file Mobile Message DOM API Proposal, V3.1 (obsolete) —
This version presents what we've already implemented or which are still under way. It can also help the coming W3C API workshop. Some updates in this version:

1. nsIDOMMozMobileMessageManager.getThreads() is going to return nsIDOMDOMCursor instead of a nsIDOMDOMRequest (please see Bug 849739).

2. Added threadId which is exposed in MobileMessageThreadListItem and can also be filtered for searching (please see Bug 850127 and Bug 854790).
Attachment #730618 - Attachment is obsolete: true
Attachment #730618 - Flags: feedback?(vyang)
Attachment #730618 - Flags: feedback?(jonas)
Attachment #731112 - Flags: feedback?(vyang)
Attachment #731112 - Flags: feedback?(jonas)
Attachment #731112 - Flags: feedback?(efc)
Correct some namings and make up some missing attributes based on what we've implemented or which are still under way.
Attachment #731112 - Attachment is obsolete: true
Attachment #731112 - Flags: feedback?(vyang)
Attachment #731112 - Flags: feedback?(efc)
Attachment #732217 - Flags: feedback?(vyang)
Attachment #732217 - Flags: feedback?(efc)
Alias: b2g-mms-dom-api
No longer blocks: 798662
No longer blocks: 840090
No longer blocks: 840087
No longer depends on: 759427
No longer blocks: 840085
No longer blocks: 840065
No longer blocks: 840059
No longer blocks: 840058
No longer blocks: 840057
No longer blocks: 840056
No longer blocks: 840055
No longer blocks: 840054
No longer blocks: 840053
No longer blocks: 840049
No longer blocks: 840047
No longer blocks: 840044
No longer blocks: 840040
No longer blocks: 810099
No longer blocks: 798664
No longer blocks: 799584
No longer blocks: 840069
No longer blocks: 840075
No longer depends on: 850140
I think the nsIDOMMozMmsMessage should include "size" - from what I can tell using the ril debugging is the message size is in the headers that are stored as "x-mms-message-size":

I/Gecko   ( 1113): MobileMessageDatabaseService: MMS: headers: {"x-mms-message-type":130,"x-mms-transaction-id":"2tid1xxxxxxxxxx_xxxxxn","x-mms-mms-version":17,"from":{"address":"+1xxxxxxxxx0","type":"PLMN"},"subject":"no subject","x-mms-message-class":"personal","x-mms-message-size":106643,"x-mms-expiry":259200,"x-mms-content-location":{"uri":"http://10.184.33.214/mms/wapenc?location=1xxxxxxxxxx_xxxxxn&rid=062"}}

Also, currently nsIDOMMozMobileMessageThread.body doesn't give anything useful when the top message is an MMS, perhaps there should be a nsIDOMMozMobileMessageThread.subject as well to send the MMS subject if there is an MMS on top of the thread.
Comment 61 is private: false
(In reply to Corey Frang [:gnarf] from comment #61)
> I think the nsIDOMMozMmsMessage should include "size" - from what I can tell
> using the ril debugging is the message size is in the headers that are
> stored as "x-mms-message-size":

Why do we need this? The |blob.size| can reveal exactly the same thing. Right?

> Also, currently nsIDOMMozMobileMessageThread.body doesn't give anything
> useful when the top message is an MMS, perhaps there should be a
> nsIDOMMozMobileMessageThread.subject as well to send the MMS subject if
> there is an MMS on top of the thread.

Good catch! This issue used to be discussed at bug 862311, comment #6. We originally planned to assign the MMS subject to the existing .body. Eventually we don't need this feature so keep .body only used for SMS for now.
(In reply to Gene Lian [:gene] from comment #62)
> (In reply to Corey Frang [:gnarf] from comment #61)
> > I think the nsIDOMMozMmsMessage should include "size" - from what I can tell
> > using the ril debugging is the message size is in the headers that are
> > stored as "x-mms-message-size":
> 
> Why do we need this? The |blob.size| can reveal exactly the same thing.
> Right?

The entire message has a size, there may be more than one attachment adding up to more.  Plus you don't have blobs for a not downloaded message, this could say "Retrieve this 300k message?"
Corey is right. In the point when we get notification indication, we don't have the blob information. If UX want to show the size of MM, we need to expose the size in nsIDOMMozMmsMessage.

(In reply to Corey Frang [:gnarf] from comment #63)
> (In reply to Gene Lian [:gene] from comment #62)
> > (In reply to Corey Frang [:gnarf] from comment #61)
> > > I think the nsIDOMMozMmsMessage should include "size" - from what I can tell
> > > using the ril debugging is the message size is in the headers that are
> > > stored as "x-mms-message-size":
> > 
> > Why do we need this? The |blob.size| can reveal exactly the same thing.
> > Right?
> 
> The entire message has a size, there may be more than one attachment adding
> up to more.  Plus you don't have blobs for a not downloaded message, this
> could say "Retrieve this 300k message?"
You are right. But for current UX wireframe, there is no size information on the notification indication message.

(In reply to Corey Frang [:gnarf] from comment #63)
> (In reply to Gene Lian [:gene] from comment #62)
> > (In reply to Corey Frang [:gnarf] from comment #61)
> > > I think the nsIDOMMozMmsMessage should include "size" - from what I can tell
> > > using the ril debugging is the message size is in the headers that are
> > > stored as "x-mms-message-size":
> > 
> > Why do we need this? The |blob.size| can reveal exactly the same thing.
> > Right?
> 
> The entire message has a size, there may be more than one attachment adding
> up to more.  Plus you don't have blobs for a not downloaded message, this
> could say "Retrieve this 300k message?"
I just filed a bug 868031 - B2G MMS: Find a better data structure for nsIDOMMozMobileMessageThread. 

We might need some feedback for making the thread view better. Welcome to discuss any solution in this bug.
Attachment #732217 - Flags: feedback?(vyang)
Attachment #732217 - Flags: feedback?(efc)
Summary: [meta] B2G MMS: Implement MMS DOM API → [meta] WebMMS: Implement MMS DOM API
Cleaning up Device Interfaces component, and mass-marking old FxOS bugs as incomplete.

If any of these bugs are still valid, please let me know.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.