RE: on Messaging

Hi Zoltan,

On 22 ene 2013 at 14:28:29, Kis, Zoltan wrote:
> 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

I agree this is low hanging fruit at least for SMS and MMS, on whose necessity everybody seems to be clear. Let's start with it. I am working on a revised version of my proposal, which I will probably publish during this week.

> - agree on the methods for the above (send, receive, etc)

Seems a reasonable next step.

> - 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

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

Received on Tuesday, 22 January 2013 16:07:29 UTC