W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2010

Re: Messaging API status and next steps

From: Bryan Sullivan <blsaws@gmail.com>
Date: Thu, 04 Nov 2010 10:05:37 +0100
To: Rich Tibbett <rich.tibbett@gmail.com>, María Ángeles Oteo <maoteo@novanotio.es>
CC: W3C DAP <public-device-apis@w3.org>
Message-ID: <C8F835F1.625D%blsaws@gmail.com>
If we are to take the approach that anything which can be done by a web
service should be out of scope for DAP, we would have little to do. This
would include (things that can be done via a web service):
* pim (contacts, calendar, tasks)
* messaging 
* gallery

Essentially anything that is not clearly stored on the local device or
information that only the device knows (e.g. Status) could be supported by a
web service.

To be sure, I do not recommend that we go that far. So for message sending,
the ability to use the locally-available content and service invocation
capabilities related to specific services such as messaging, are still
important to define as APIs even if we do have already have useful/usable
methods such as URI schemes and web services.

Bryan | AT&T

On 11/3/10 8:34 AM, "Rich Tibbett" <rich.tibbett@gmail.com> wrote:

> 2010/11/2 María Ángeles Oteo <maoteo@novanotio.es>
>> Formerly, we decided to split messaging API in 3 parts:
>>    A) Sending and Subscription
>>    B) Reading messages from the device memory
>>    C) Managing messages in device memory (e.g. folder management)
>>  Based on the comments about security and the need to provide multipart
>> handling capability for reception we suggest to change the structure of the
>> split:
>>    A) Sending: Simple API with no MIME multipart support.
>>    B) Subscribing and reading: We need to add MIME multipart support for
>> this one and filters (hopefully the same) for both subscription and message
>> retrieval: subscribe only to SMSs coming from a particular number or
>> retrieve from the device memory only the messages that match that filter.
>>    C) Message management.
> Assuming we are creating an API to live for 100 years, it's not clear why we
> would want to be explicitly concrete in to the web platform today's
> technologies such as SMS, MMS and Email when we could provide a much nicer
> abstract model to achieve the same effect.
> I am, personally, happy using existing and future web services to send and
> receive messages via SMS, MMS and Email. In addition I can use sms:, mmsto:
> and mailto: URLs to launch my native client when required. Sending messages
> seems sorted.
> For me, a suitable abstraction here would be to focus only on a generic Push
> Notification API for the web - to allow incoming messages from a multitude of
> sources, including SMS, MMS and Email. The receiving/listening functionality
> could be abstracted to allow for more broad push notifications to occur within
> the browser.
> - Rich
Received on Thursday, 4 November 2010 09:06:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:24 UTC