WebAPI/WebSMS: Difference between revisions

no edit summary
No edit summary
 
(17 intermediate revisions by 3 users not shown)
Line 19: Line 19:
   interface SmsManager
   interface SmsManager
   {
   {
     SmsRequest      send(in DOMString number, in DOMString message);
     SmsRequest      send(DOMString number, DOMString message);
     void            suggestSend(in DOMString number, in DOMString message);
     SmsRequest[]    send(DOMString[] number, DOMString message);
     unsigned short  getNumberOfMessagesForText(in DOMString text);
     unsigned short  getNumberOfMessagesForText(in DOMString text);
     SMSRequest      delete(in long uuid);
     SMSRequest      delete(in long id);                       // request.result == boolean
     SMSRequest      delete(in SmsMessage message);
     SMSRequest      delete(in SmsMessage message);           // request.result == boolean
     SMSRequest      getMessage(in long uuid);                  // request.result == SMSMessage
     SMSRequest      getMessage(in long id);                  // request.result == SMSMessage
     SMSRequest      getMessages(in SMSFilter filter, bool reverse); // request.result == SMSIterator
     SMSRequest      getMessages(in SMSFilter filter, bool reverse); // request.result == SMSIterator
    SMSRequest      markMessageRead(long id, boolean aValue); // request.result == boolean
   };
   };


Comments:
Comments:
* ''send'' and ''suggestSend'' could take an array of numbers.
* Should use opaque objects as message-identifiers rather than longs?
* suggestSend could be removed in favor of Web Activities.
* maybe ''delete'' shouldn't return a SMSRequest?


   interface SmsRequest
   interface SmsRequest
   {
   {
     readonly attribute unsigned short readyState;
     readonly attribute DOMString readyState; // "processing" or "done"
     readonly attribute unsigned short errorCode;
     readonly attribute DOMError? error;
     attribute EventListener           onsuccess;
     attribute EventListener     onsuccess;
     attribute EventListener           onerror;
     attribute EventListener     onerror;
     attribute readonly SmsMessage?   message;
     attribute readonly any?     result;
   };
   };


   interface SmsMessage
   interface SmsMessage
   {
   {
     readonly attribute long      uuid;
     readonly attribute long      id;
    readonly attribute DOMString delivery; // could be "sent" or "received"
     readonly attribute DOMString sender;
     readonly attribute DOMString sender;
     readonly attribute DOMString receiver;
     readonly attribute DOMString receiver;
     readonly attribute DOMString body;
     readonly attribute DOMString body;
     readonly attribute Date      timestamp;
     readonly attribute Date      timestamp;
    readonly attribute boolean  read;
   };
   };


Comments:
Comments:
* Have an array of receiver?
* We have .sender and .receiver because someone can have multiple number or change numbers. We could merge them to .number if that seems necessary.
* Add a status attribute that can be equals to SENT or RECEIVED?
* Merge sender/receiver and use the status attribute?


  [Constructor]
   interface SmsFilter {
   interface SmsFilter {
     Date             startDate;
     Date?        startDate;
     Date             endDate;
     Date?        endDate;
     DOMString[]     numbers;
     DOMString[]? numbers;
     DOMString       body;
    [TreatNullAs=EmptyString, TreatUndefinedAs=EmptyString]
     DOMString?  delivery; // whether "sent" or "received"
    boolean?    read;
   };
   };


Comments:
Comments:
* Maybe add a ''isRead'' field?
* When we will have MMS support, we would have to add a .type property to allow looking for SMS or MMS.
* Add a ''type'' field that could be SMS or MMS;
* For the moment, there is no way to filter according to the content of a message because we didn't find a nice way to do it. This could be added later though.
* Maybe add a ''status'' field that could be SENT or RECEIVED?
* Can we make the ''body'' field better to allow AND/OR operations?


   interface SmsIterator {
   interface SmsIterator {
Line 76: Line 76:


In addition of these interfaces, there is a new event:
In addition of these interfaces, there is a new event:
  [Constructor(DOMString type, optional SmsEventInit smsEventInitDict)]
   interface SmsEvent : Event
   interface SmsEvent : Event
   {
   {
     void initSmsEvent(in DOMString eventTypeArg,
     readonly attribute SmsMessage message;
                      in boolean canBubbleArg,
  };
                      in boolean cancelableArg,
 
                      in SmsMessage message);
  dictionary SmsEventInit : EventInit {
    readonly attribute SmsMessage message;
    SmsMessage message;
  }
  }


The ''SmsEvent'' is used for the following events:
The ''SmsEvent'' is used for the following events:
Line 91: Line 93:
These events carry the SMS in ''event.message''.
These events carry the SMS in ''event.message''.
A security story has to be defined for these events.
A security story has to be defined for these events.
[[Category:Web APIs]]
Confirmed users
1,340

edits