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

Hi, 
Revisiting an old thread (based on yesterday's discussion), I think the main/only reason to spell out messaging technology had to do with security, being able to map permissions to method names. 
We did explore the general messaging api a year back or so (Max F wrote a proposal for that), which did away with the sendSMS ugliness, but that approach was dropped because of the permission issue. 
(btw the old proposal did not use URI schemes, it defined message types instead, the old proposal is also why we have the table in chapter 4). 

While I certainly still see the need for being messaging technology agnostic, as well as benefit in aligning technology naming with existing scheme names, I don't really understand how relying on the URI schemes makes things so much better than having msg.create(type, to, ...), msg.setParameter(...) and msg.send() but I'm probably missing the point here.

Regarding Rich's final (no specific messaging API at all) solution, that might work, but wouldn't it also just move the headache to the developer instead? In particular if device local access is needed?

Best regards,
Niklas
 

> -----Original Message-----
> From: public-device-apis-request@w3.org 
> [mailto:public-device-apis-request@w3.org] On Behalf Of Rich Tibbett
> Sent: den 28 januari 2011 16:29
> To: Dominique Hazael-Massieux
> Cc: public-device-apis
> Subject: 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 Thursday, 10 February 2011 14:14:07 UTC