Re: Messaging API proposal

On Thu, Mar 10, 2011 at 10:28 AM, Dominique Hazael-Massieux <dom@w3.org>wrote:

> Le jeudi 10 mars 2011 à 10:10 +0100, Rich Tibbett a écrit :


> > 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.
>
> WhileI can see the theoretical appeal of such an approach, "POST" really
> only has meaning with HTTP and HTTPs, not for other URI schemes. We
> could explain how to pretend POST had a meaning for other schemes e.g.
> within an XMLHttpRequest extension (which is what I alluded to in [1]),
> but I very much doubt that defining what POST means for mmsto: or
>  mailto: would be acceptable within an Internet Draft.


> 1.
> http://lists.w3.org/Archives/Public/public-device-apis/2011Jan/0104.html


It is a valid consideration about the complexity of doing that. My concerns
on producing such a Messaging API (and to a similar extent, other APIs) run
to more fundamental aspects than that.

We've talked about standards success factors previously. For me producing
specifications is not the end-game; ubiquitous support across all UAs is. If
an API is not ubiquitously accessible across all UAs then web developers
can't reliably code against such APIs. If it's not clear that there is
enough incentive from a least a handful of UA companies to implement an API
then that API has a significantly high likelihood of failing. That's where
we are with any proposal for a Messaging API today. We should take in to
account the risk factors as a way to evaluate all proposals to produce
deliverables going forward. From my reasoning above, producing any APIs
carry a high risk factor.

We should give ourselves the highest possibility for producing successful
specifications backed by ubiquitous implementations by working on
specifications that have a large level of interest.

Going back to the non-API proposal, if we were to utilize the uri schemes
then it's not an absolute requirement for all UAs to implement such a
scheme. UAs could theoretically implement uri schemes without requiring any
reliance on other vendors to reciprocally implement anything. IMO, producing
uri schemes carries a lower risk factor than APIs in this case.

That's currently how I see it. If others want to help me with that
understanding please do provide feedback.

(and I'm sorry to get 'meta' on this thread but I hope we can take something
from this discussion).

- Rich