Re: Messaging API proposal

Rich Tibbett wrote:
> 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])

Actually, Android Content URIs:

[1] http://developer.android.com/reference/android/content/Intent.html

> - ...
>
> 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:17:08 UTC