Re: [Messaging API based on webinos]

On 03/01/13 15:42, SULLIVAN, BRYAN L wrote:
> I agree with Jose. We have gone down this path a couple of times already
> (in BONDI and WAC, and DAP) and it was found that trying to have "one
> messaging API to rule them all" is tempting but ultimately too
> functionally warping to the needs of the individual messaging systems.
> Attachments and mailbox/folder management are examples of significantly
> divergent (or contextually irrelevant) functions.

As I already said in this mailing list, I am strongly against a
Messaging API that includes email and IM too. I think we should stay on
the SMS/MMS level.

I am generally against having an API for email or IM in the Web and I
think the Raw Socket API + JS libraries should be enough but even if we
do not agree with that, I think merging multiple different technologies
in the same specification makes things harder to do because each
technology have its own specificities. Even trying to merge SMS and MMS
in the same specification isn't trivial.

For example, this specification doesn't handle the following basic use
case in a SMS application:
- I sent a message to Bob. Was it sent successfully? Was it delivered
successfully? (the spec has one callback which I assume is there for
sent but not delivered)
- I am sending a long message to Bob and I don't have unlimited text
messages with my plan. How much actual SMS are going to be sent?

In addition of specificities, there is the case were something is added
for one type of message and doesn't apply for others and makes things weird:
- What happens if a consumer of the API tries to send a SMS with a CC
field? Should the SMS be sent to the CC'd numbers?
- What happens if a SMS is sent with an attachment? Should it be
converted to a MMS?

A good API should likely ignore the CC and attachment field if the
message is a SMS but having an API with fields being ignored depending
another field's value is confusing. Think of HTMLInputElement's mess.

I also have a few comments regarding the API itself.
I am not sure why you are using onSMS, onEmail, [...] and unsubscribe()
instead of the very common addEventListener / removeEventListener.
It is also not clear how you handle reading changes. I wasn't able to
find how a message was marked as read/unread even if you can access the
read state and search based on that.
You are also missing a delete() method.

Cheers,
--
Mounir

Received on Friday, 4 January 2013 15:54:59 UTC