Re: on Messaging

Hello,

There was no answer on email below (please read).
Are we counting on discussing all these issues on a face to face meeting?
Nevertheless, I try pinging, since email discussion still makes sense
before f2f.
I have moved the Intel proposal for Messaging into the Messaging
directory, with the intention to align them as much as possible.

Could we move forward with the Messaging specs as follows:
- agree on the structure of SMS, MMS and USSD messages
- agree on the methods for the above (send, receive, etc)
- discuss adding the notion of messaging services (see below)
- discuss IM and group chat
- discuss email.

The aim is to discuss all messaging types in this round, especially
from the converged messaging point of view brought up by Bryan. The
specs look complex, but in the end the use cases can be supported by
adding the notion of "messaging service" (which is a user account on a
given provider service, usually tied to a protocol or a set of
protocols), with which applications could support e.g. SMS over IP or
various message bridging solutions. The Intel proposal was designed
with these use cases in mind, and I would like to hear feedback
whether is it good enough, and simple enough.

In the simplest case, this would just be an opaque identifier in the
methods (as in Telephony), but in Messaging this was not enough IMO,
and I needed to define a separate object for handling the use cases.
Ultimately, it was mainly because the different messaging services can
receive messages in parallel, but all incoming calls from all
telephony services compete for getting picked up, therefore need
central arbitration.

I am open for alternative suggestions.

Best regards,
Zoltan

On Thu, Jan 10, 2013 at 10:08 PM, Kis, Zoltan <zoltan.kis@intel.com> wrote:
> 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 Tuesday, 22 January 2013 13:29:03 UTC