Re: Messaging API proposal

Dominique Hazael-Massieux wrote:
> Hi,
>
> As discussed on the call today [1], maybe the best way to go about the
> messaging API is to make it as simple as possible by reusing as much of
> the URI schemes capabilities (which already handle to/cc/body/subject
> etc), and have a simple:
>    navigator.sendMessage("mailto:dom@w3.org?subject=Your%20idea%20is%
> 20fantastic&body=We%20love%you", [Blob1, Blob2], errorCB)
> where the list of Blobs would add attachments.
>
> In WebIDL term, we would need to define a single method, à la
>          caller void sendMessage (DOMString to, sequence<Blob>
>          attachments, messagingErrorCB? errorCB);
> and the messagingErrorCB interface.
>
> How does that look?

This is a good simple proposal if we were to go down the API route. I 
wonder if we need an API in the first place though since sms URIs 
provide all of the functionality required for SMS and mmsto URIs provide 
all of the functionality required for MMS, minus attachments (as I 
discussed on the call).

I'd really like to see a rough Internet Draft around adding attachments 
to the mmsto URI scheme. Effectively, mmsto URIs could act in a similar 
way to HTTP requests: the existing mmsto URI scheme could be enhanced to 
make mmsto URIs accept attachments as POSTed multi-part message contents 
of a request.

Defining HTTP-like Device URI schemes for different features might also 
present some novel and really interesting/compatible ways to interact 
with the device.

For example, it might be nice if we had both a people:// and person:// 
uri schemes with which to interact with contact information in a 
HTTP-like, RESTful manner (GET/POST/PUT/DELETE). If we had that we would 
have successfully designed out the need for an API (!).

Basically, I'm open to exploring how to utilize the web's killer feature 
(the URI) a little better for exposing device features while a.) not 
requiring a locally running web server to serve those requests and b.) 
allowing standard fallback for non-supported URIs (e.g. serving up a 
HTTP 400 Bad Request as browser do today for non-supported URI schemes).

URIs also provide a lead-in to an acceptable user experience. Here are 
some examples: if a user invokes:

- an mmsto URI, the UA could resolve to an MMS editor.
- a people URI, the UA could resolve to a Contacts Picker
- a person URI, the UA could resolve to an individual contact (ala 
Android Contact URIs [1])
- ...

Anyway, this is the seed of the seed of an idea but I think it's 
something we might want to explore, and possibly also recharter with.

- Rich

Received on Thursday, 10 March 2011 09:11:27 UTC