on Messaging

Hello,

There are a couple of Messaging API proposals.

I would suggest the following process:
- let's review each proposal, eventually make a comparison
- let's try to agree first on the structure/properties of SMS, MMS,
USSD, and also email, IM and group chat. I expect this will be
relatively easy. Let's start with SMS, MMS and USSD, and continue then
with instant messaging (peer to peer), then group chat and lastly
email.
- then, agree on search/filtering, storage, asynchronous operations
and how to iterate over result sets. This will be a more difficult
discussion, but also other API's may benefit (Contacts, call history,
etc).

***

About the Intel proposal:
- A key part is supporting messaging services (multiple SIM cards, IM
accounts, email accounts, etc).
- All functionality is provided by such services, which can be
enumerated, even searched for, and monitored for changes (this part is
nice, but not that important, it can also be an array of services with
polling for changes, if that makes things simpler for start).
- There is one default service for each messaging type: SMS, MMS,
USSD, email, IM, group chat. This permits accessing the functionality
in a nicely separated way (navigator.sms, navigator.mms, etc, or via a
messaging object like navigator.messaging.sms, etc). In the same time,
the joint spec makes much shorter defining the overlapping property
sets. Also, it is compatible with the other API's which support only
one service of a kind.
- in the beginning I would keep all messaging types in one spec. Later
they could be split, if such need arises. However, I would defer that
decision to a later point.
- there has been discussion about storage and search/filters. I would
defer also this to a later point. Let's see how much synergy we can
obtain when defining the structures. We could open another thread on
each of these.

Best regards,
Zoltan

Received on Thursday, 10 January 2013 20:09:22 UTC