Re: Messaging API status and next steps

Rich,
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.
> 
> WDYT?
> 
> - Rich
>  
>