- From: Micheil Smith <micheil@brandedcode.com>
- Date: Tue, 19 Apr 2011 19:36:23 +1000
- To: public-device-apis@w3.org
Hi All, I saw the recently changed Device Messaging API draft [1], and couldn't help but feel that it seems extremely un-javascript-ish. I saw that the authors are looking for feedback on the API, so I composed an alternative API to the current one. My proposal is very similar to the previous API [2], which I felt fairly good as far as a JavaScript API, however, it has the following changes: (The full WebIDL proposal is at: https://gist.github.com/ebd79f6cd4f620fc4fa7 ) 1) The navigator.device.messaging.* methods have been made Constructors instead, such that the following is valid: var message = new navigator.device.messaging.SMS({ to: "+46000000001", body: "Welcome to Atlantis" }); 2) All Messaging Constructors inherit from the DOMEvents EventTarget interface. Example: message.addEventListener("sent", function() { alert("Your SMS message was sent!"); }); 3) All Message Objects have a send and abort method. 4) All Message Objects have a readyState, and readyState constants defined. 5) All Message Objects have properties for various events (see onsend, onsent, onerror) 6) All arguments or properties that were an Array of Something, eg, DOMString[], are now able to be either a DOMString (for the singular) or a DOMString[], such that the following work: var message = new navigator.device.messaging.SMS({ to: "+46000000001", body: "Welcome to Atlantis" }); var message2 = new navigator.device.messaging.SMS({ to: ["+46000000001", "+46000000002", "+46000000003"], body: "Welcome to Atlantis" }); 7) Attachments are now of type "sequence<Blob>". The full WebIDL proposal is at: https://gist.github.com/ebd79f6cd4f620fc4fa7 I think that anything where there is the possibility of multiple callbacks should be instances of EventTarget [3], as this is a well known and easy to use API, which allows for developers to optionally listen for events. In the case of the Messaging API, sometimes a developer may wish to send a "fire-and-forget" message. On each Message Object, I have introduced a readyState property, as well as readyState constants, the usage of this is to be able to poll for a state change, as is available in the XMLHTTPRequest API [4]. Let me know what you think, or consider taking some of this feedback on board. References: [1] http://www.w3.org/TR/2011/WD-messaging-api-20110414/ [2] http://www.w3.org/TR/2011/WD-messaging-api-20110120/ [3] http://www.w3.org/TR/DOM-Level-2-Events/idl/events.idl [4] http://www.w3.org/TR/XMLHttpRequest/ Cheers / Regards, Micheil Smith -- BrandedCode.com
Received on Wednesday, 20 April 2011 13:15:10 UTC