W3C home > Mailing lists > Public > public-device-apis@w3.org > April 2011

[Messaging API] Feedback / Proposal

From: Micheil Smith <micheil@brandedcode.com>
Date: Tue, 19 Apr 2011 19:36:23 +1000
To: public-device-apis@w3.org
Message-Id: <E14A1FEC-86EA-4FDD-8404-2110938C3AE9@brandedcode.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:20 GMT