Messaging API usage (was: Agenda - Distributed Meeting 2011-01-12)

Hi Rich,

Le mercredi 12 janvier 2011 à 12:40 +0100, Rich Tibbett a écrit :
> I can say for certain that it would be a bad idea to hard code
> specific technologies, in this case SMS, Email or MMS in to the Web
> Platform in the long term. While SMS is ubiquitous today who knows how
> long it will really stick around. Also, MMS is a dubious technology to
> include even today considering usage.

I could see value in unlinking the communication protocol from
interfaces names, and instead use the URI schemes as the way to tie to a
specific protocol; this would be more flexible and better integrated in
the Web architecture.

That said, I still think we should publish the existing editors draft as
an updated draft of the document, given how we've vastly reduced the
scope since the previous draft we published during the summer.

> Instead, a Messaging API should be more bus-like to allow the creation
> of formatted messages. Considering we already have sms, mmsto and
> mailto urls for launching a messaging composer (and prefilling the
> fields) and also that simple web APIs can accomplish the sending
> aspects, I don't see any need for this API.

The value of the API (as highlighted in the document) is to add what's
the current URI schemes don't allow, namely attachments; it also offers
a much saner way to compose body of messages.

> Besides all of these objections I don't see how the Messaging API is
> workable in the browser-context. What is the intended user experience,
> if there is one? 

It's intended to be exactly the same as the current related URI schemes
allow (i.e. triggering the start of an external application or web
site). I don't think it needs any specific prompting or permissioning as
a result. If the current document doesn't make that clear, it would be
good to point out what made you believe otherwise.

Dom

Received on Wednesday, 12 January 2011 11:49:21 UTC