Re: Messaging API proposal

On Mar 10, 2011, at 10:10 , Rich Tibbett wrote:
> 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.

It doesn't help SMS much, but it does work for mmsto and mailto at least. Given how simple an API it is, and that it addresses the use cases, I like it.

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

My experience in doing this for the widget: URI scheme has left me dubitative. Sure, it kind of works. But at the end of the day, if you're going to be defining a URI scheme to have HTTP semantics then you should just use the HTTP URI scheme. Otherwise you end up having to specify a whole lot of things and implement quite a few aspects that you wouldn't normally touch — HTTP isn't all that trivial, for all that we take it for granted.

> 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 (!).

Again, if they're HTTP-like and RESTful, why not use HTTP? There's the domain name problem but we could imagine a .app or .api reserved TLD that would handle that. I'm not sure that trying to map everything that way is the simplest approach, really.

Android's Content URIs are certainly interesting, but as far as I know they're not HTTP-like. They're used with Intents (which can be seen as REST-like for sure) and not with XHR. If we want to head towards a generic system, I think we should start with an Intents-like model (or something supporting similar capabilities), and *then* we can figure out if we want to replace some APIs with it.

This API is so small (and it addresses a few, simple use cases that aren't addressed today) it does not seem to me that we ought to wait until we've built a cathedral that can handle it. If we get the cathedral right, it won't be a big problem that there's a little bit of overlap in the system.

> 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).

We actually looked at that before, there's even some code in CVS :)

-- 
Robin Berjon - http://berjon.com/

Received on Thursday, 10 March 2011 09:54:47 UTC