Re: Messaging API status and next steps

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