Messaging API proposal from Intel

Hello,

Intel's proposal for a basis for discussions on the Web Messaging API
can be found at
https://github.com/otcshare/sysapps
and can be viewed here:
http://htmlpreview.github.com/?https://github.com/otcshare/sysapps/blob/master/proposals/Messaging_Intel/Messaging.html
(until the pull request is merged into https://github.com/sysapps/sysapps ).

This covers SMS, MMS, USSD, email, instant messaging, group chat. The
reason for this is the quite large overlap across different types of
messaging. I propose we discuss API's for each type separately, for
start.

Supporting the notion of messaging services is a key concept in this
proposal, and it coherently also appears in Intel's Telephony
proposal, although with a different API design (objects used in
Messaging and only service id used in Telephony). This has
implications on other API's as well (e.g. Contacts).

In addition, we can't avoid data model and search related topics:
filters, (live) search, (live) data models, with performance in mind.
I also included a spec for async request handling combined with
iterating over the result set. I see that was also a concern (with a
similar but different solution) in the Mozilla/Telefonica proposal, so
we may want to agree on a pattern.

As it appears from earlier discussion, there is interest in 2 major
architectures on this group:
- minimal native middleware: do as much as possible in JS, including
email, and IM
- minimal web runtime: do as much as possible in native middleware,
and only expose that functionality to the web runtime.

Both will be best suited to their designated group of target devices
and applications.
Intel is interested in both, so I would like to reach consensus to
have an API which supports both architectures.

So the goal in Messaging discussions would be to
- distill key use cases that the API's need to support
- find consensus on SMS, MMS, and USSD API's
- keep email, IM, and group chat API informative, but still specified
- find good patterns on how to deal with data models and search.

Happy and efficient New Year to everyone!

Best regards,
Zoltan

Received on Monday, 31 December 2012 14:25:48 UTC