RE: Messaging API status and next steps

+1

 

Suresh

 

From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Bryan Sullivan
Sent: Thursday, November 04, 2010 4:06 AM
To: Rich Tibbett; María Ángeles Oteo
Cc: W3C DAP
Subject: 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
 


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.