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

On Wed, Jan 12, 2011 at 1:21 PM, Rich Tibbett <rich.tibbett@gmail.com>wrote:

>
>
> On Wed, Jan 12, 2011 at 12:49 PM, Dominique Hazael-Massieux <dom@w3.org>wrote:
>
>> 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 would be good.
>
>
>>
>> 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.
>
>
> I'm questioning the much bigger issue of the rational for this
> specification in the first place, not about milestones on the
> specification's roadmap.
>
>
>>
>> > 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.
>>
>
> On the 'saner way to compose body of messages' are you saying that URL
> Encoding a body string is the problem with URI schemes?
>
> Assuming you compose messages and subsequently encode them for URI passing
> then I wouldn't say that URL encoding of a string of data is a problem.
>
> Attachments provide a better use case but why, for example, could we not
> extend existing technologies - why could we not pass Blob URIs pointing to
> attachment files in the URI schemes instead?
>
>
>>
>> > 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.
>>
>
> The user experience you mention didn't jump out at me on reading. Perhaps
> either the Abstract or Scope could clarify exactly what is covered, what the
> intended user experience is (informative would be fine) and how it works
> with either a local device or web service. The spec should also highlight
> the benefits of the API over existing methods (i.e. URI schemes) and why
> this stuff could not be integrated with these existing methods.
>

Also the 'send()' methods say the following: 'Asynchronous method to request
sending an SMS. Upon a successful invocation the message is delivered to the
network.'. That's incongrous with your description above or starting an
external application or web site. Clarification in the Abstract or Scope
would be good.


> - Rich
>