Closed
Bug 760065
(b2g-mms-dom-api)
Opened 13 years ago
Closed 7 years ago
[meta] WebMMS: Implement MMS DOM API
Categories
(Core :: DOM: Device Interfaces, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: ptseng, Assigned: vicamo)
References
Details
Attachments
(1 file, 39 obsolete files)
(deleted),
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...
Reporter | ||
Comment 1•13 years ago
|
||
According the Description, create the MMS DOM
Source codes on github: https://github.com/PriceTseng/mozilla-central/tree/MMS-DOM
Reporter | ||
Comment 2•13 years ago
|
||
(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/
Assignee | ||
Comment 3•13 years ago
|
||
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/
Assignee | ||
Comment 4•13 years ago
|
||
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
Assignee | ||
Comment 5•13 years ago
|
||
Assignee | ||
Comment 6•13 years ago
|
||
Sync/refactoring https://github.com/PriceTseng/mozilla-central/commit/ff3eca4c9667c569d811203a77237ddbdeb34c1c done ;)
Assignee | ||
Comment 7•13 years ago
|
||
Assignee | ||
Comment 8•13 years ago
|
||
Assignee | ||
Comment 9•13 years ago
|
||
Attachment #634334 -
Attachment is obsolete: true
Assignee | ||
Comment 10•13 years ago
|
||
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
Assignee | ||
Comment 11•13 years ago
|
||
Assignee | ||
Comment 12•13 years ago
|
||
Comment on attachment 634336 [details] [diff] [review]
Part 100: add MmsAttachmentStorage : WIP
also obsoleted by part 2
Attachment #634336 -
Attachment is obsolete: true
Assignee | ||
Comment 13•13 years ago
|
||
Attachment #634510 -
Attachment is obsolete: true
Assignee | ||
Comment 14•13 years ago
|
||
test MozMmsMessage attributes
Attachment #634339 -
Attachment is obsolete: true
Assignee | ||
Comment 15•13 years ago
|
||
sync interface definitions described in https://groups.google.com/d/msg/mozilla.dev.webapi/IuayswaeYO4/wmIQOa17Sv8J
Attachment #634849 -
Attachment is obsolete: true
Assignee | ||
Comment 16•13 years ago
|
||
sync event interface definitions described in https://groups.google.com/d/msg/mozilla.dev.webapi/IuayswaeYO4/wmIQOa17Sv8J
Attachment #634850 -
Attachment is obsolete: true
Assignee | ||
Comment 17•13 years ago
|
||
Support creating MozMmsMessage instance from MmsService. There is still one last thing to do: the attachment interface.
Attachment #635368 -
Attachment is obsolete: true
Assignee | ||
Comment 18•13 years ago
|
||
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
Assignee | ||
Comment 19•13 years ago
|
||
add tests for MmsManager onreceived & ondelivered events.
Attachment #634853 -
Attachment is obsolete: true
Reporter | ||
Comment 20•13 years ago
|
||
Add the nsIDOMMmsAttchment interface
Source codes on github: https://github.com/PriceTseng/mozilla-central/tree/mms/dom-api/
Updated•12 years ago
|
blocking-basecamp: --- → ?
Comment 21•12 years ago
|
||
MMS is desired to be ready for basecamp, but does not actually block.
blocking-basecamp: ? → -
Assignee | ||
Comment 23•12 years ago
|
||
Attachment #635659 -
Attachment is obsolete: true
Assignee | ||
Comment 24•12 years ago
|
||
Assignee | ||
Comment 25•12 years ago
|
||
Attachment #635661 -
Attachment is obsolete: true
Assignee | ||
Comment 26•12 years ago
|
||
Assignee | ||
Updated•12 years ago
|
Attachment #636239 -
Attachment is obsolete: true
Assignee | ||
Comment 28•12 years ago
|
||
Use Date.getTime() instead of Date.valueOf()
Attachment #641336 -
Attachment is obsolete: true
Assignee | ||
Comment 29•12 years ago
|
||
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
Assignee | ||
Comment 30•12 years ago
|
||
There seems to be only one thing left unfinished: send interface.
Assignee: nobody → vyang
Attachment #634851 -
Attachment is obsolete: true
Assignee | ||
Comment 31•12 years ago
|
||
Attachment #635663 -
Attachment is obsolete: true
Assignee | ||
Comment 32•12 years ago
|
||
Attachment #641333 -
Attachment is obsolete: true
Assignee | ||
Comment 33•12 years ago
|
||
Attachment #641334 -
Attachment is obsolete: true
Assignee | ||
Comment 34•12 years ago
|
||
Attachment #641829 -
Attachment is obsolete: true
Assignee | ||
Comment 35•12 years ago
|
||
Attachment #641830 -
Attachment is obsolete: true
Assignee | ||
Comment 36•12 years ago
|
||
Attachment #641835 -
Attachment is obsolete: true
Assignee | ||
Comment 37•12 years ago
|
||
Attachment #641836 -
Attachment is obsolete: true
Assignee | ||
Updated•12 years ago
|
Assignee | ||
Updated•12 years ago
|
Blocks: b2g-mms-ui, 804679
Assignee | ||
Comment 38•12 years ago
|
||
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 39•12 years ago
|
||
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-
Comment 40•12 years ago
|
||
Updated•12 years ago
|
Attachment #684240 -
Attachment mime type: text/x-idl → text/plain
Assignee | ||
Comment 41•12 years ago
|
||
(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"
Assignee | ||
Comment 42•12 years ago
|
||
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.
Assignee | ||
Comment 43•12 years ago
|
||
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)
Assignee | ||
Comment 44•12 years ago
|
||
(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"
Assignee | ||
Comment 46•12 years ago
|
||
(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+
Updated•12 years ago
|
Attachment #684381 -
Flags: feedback?(kyle) → feedback+
Comment 49•12 years ago
|
||
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 50•12 years ago
|
||
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).
Comment 52•12 years ago
|
||
(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.
Comment 53•12 years ago
|
||
(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
Assignee | ||
Updated•12 years ago
|
blocking-b2g: --- → leo?
Updated•12 years ago
|
No longer blocks: b2g-mms-ui
Comment 54•12 years ago
|
||
Blocking- because metabug. Please nominate the bugs that have the actual work.
blocking-b2g: leo? → -
Updated•12 years ago
|
Summary: B2G MMS: Implement MMS DOM API → [meta] B2G MMS: Implement MMS DOM API
Comment 55•12 years ago
|
||
I'll update all the DOM API spec tomorrow based on our previous discussions offline. Please stay tuned.
Updated•12 years ago
|
Comment 56•12 years ago
|
||
Attachment #730618 -
Flags: feedback?(mounir)
Attachment #730618 -
Flags: feedback?(jonas)
Updated•12 years ago
|
Attachment #684381 -
Attachment is obsolete: true
Comment 57•12 years ago
|
||
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 58•12 years ago
|
||
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)
Comment 59•12 years ago
|
||
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)
Attachment #731112 -
Flags: feedback?(jonas) → feedback+
Comment 60•12 years ago
|
||
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)
Updated•12 years ago
|
Attachment #732217 -
Flags: feedback?(efc)
Updated•12 years ago
|
Alias: b2g-mms-dom-api
Comment 61•12 years ago
|
||
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
Comment 62•12 years ago
|
||
(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.
Comment 63•12 years ago
|
||
(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?"
Comment 64•12 years ago
|
||
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?"
Comment 65•12 years ago
|
||
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?"
Comment 66•12 years ago
|
||
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.
Updated•11 years ago
|
Attachment #732217 -
Flags: feedback?(vyang)
Attachment #732217 -
Flags: feedback?(efc)
Assignee | ||
Updated•11 years ago
|
Summary: [meta] B2G MMS: Implement MMS DOM API → [meta] WebMMS: Implement MMS DOM API
Comment 67•7 years ago
|
||
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: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•