Re: Messaging API and URI schemes (ISSUE-107)

Dominique Hazael-Massieux wrote:
> Hi,
>
> Now that we have managed to published an updated version of the
> messaging API, I would like to come back to the point that Rich raised a
> couple of weeks ago (and on which I've just raised an issue, ISSUE-107)
>
> There were indeed discussions on how we could make better use of the
> existing URI schemes in the messaging API, with two goals:
> * making the API better integrated in the Web architecture
> * making it easier to integrate new messaging protocols
>
> My thoughts on this:
> * relying on URI schemes rather than creating new methods names for each
> protocol sounds indeed better
>
> * such an API would essentially look like
>          msg = device.message.create("mailto:dom@w3.org", additionalMessageProperties);
>          msg.send(successCB, errorCB)
>
> * such an API would probably deserve to get a lot of inspiration from
> XMLHttpRequest; I've idly wondered if extending XMLHttpRequest to handle
> non-HTTP URIs would be an approach to this — but I'm not sure the
> practical gain would be that high; in any case, we should pay attention
> to the similarities

Thanks for picking this up, Dom.

We could fully model on the XHR approach. e.g.:

// With attachment (HTTP POST)
new msgr = new MessageRequest();
msgr.open('POST', 'mmsTo:+44123456789?body=Hi%20there');
// Add an attachment file and send
msgr.send('data:....');

// Without attachment (HTTP GET)
new msgr = new MessageRequest();
// Send
msgr.open('GET', 'mmsTo:+44123456789?body=Hi%20there');
msgr.send();


Or we could just use XMLHttpRequest as it stands with a server-side gateway:

var xhr = new XMLHttpRequest();
xhr.open('POST', '/myMMSSender.php?number=+44123456789&body=Hi%20there');
xhr.onreadystatechange = function() {
   if(this.readyState < 4) return;
   alert('Message sent successfully');
};
xhr.send('data:....attachment....');


Both approaches cover the two notable use cases of being able to send 
attachments and being notified on sending success/failure. The second 
use case is notable in that it is already possible to do on the web 
without having to add more standard APIs.

On the receiving aspects, to listen for incoming messages we could use a 
basic HTML5 EventSource:

var evtSrc = new EventSource('/myMMSReceiver.php');
evtSrc.onmessage = function( evt ) {
   alert( "MMS Message received from " +
             evt.data.from + ": " + evt.data.body );
};


I believe the above use cases can be used to sufficiently cover all of 
our original Messaging requirements [1] and more.

Third-party libraries would be free to roll their own Messaging APIs via 
the XmlHttpRequest and EventSource interaction models above (it could 
even come out looking exactly like the Messaging API draft but it 
doesn't need to be standardized).

- Rich

[1] http://www.w3.org/TR/dap-api-reqs/#messaging


>
> Dom
>
>

Received on Friday, 28 January 2011 15:29:30 UTC