Re: Messaging - SMS API draft

On Fri, Oct 26, 2012 at 1:41 PM, Mounir Lamouri <mounir@lamouri.fr> wrote:
> On 10/25/2012 03:01 PM, Poussa, Sakari wrote:
>> On 10/24/12 8:51 PM, "Kis, Zoltan" <zoltan.kis@intel.com<mailto:zoltan.kis@intel.com>> wrote:
>>
>> - IMO we should design this API together with MMS, email and p2p IM API's, in order to align them as much as possible, since many attributes and use cases will be common. Should I send proposals for these?
>>
>> In Tizen messaging API we managed to combine all of the above under one API. We can at least try to do the same here and get feedback if it is sensible of not. So I am suggesting that f.ex Zoltan would propose an API which includes more than just SMS. Then we can at least see how much overhead that would bring in.
>
> I agree that MMS should be included in this API but we could likely make
> this happen in two steps. However, the first released document should
> definitely include MMS.

MMS is using SMTP on the MM4 interface. So the two specifications
(email and MMS) will be almost completely the same, except when you
dive into SMIL (which we don't intend to explicitly do in these API's,
it will be the middleware's problem).

>
> Regarding email, P2P, IM and all other protocols, I strongly disagree
> with including those in this specification. As usual with Mozilla, my
> opinion isn't the official Mozilla's position but the deeds prove that
> this isn't the way we are going. In the phase 1 of the charter [1],
> there is the Raw Sockets API. Google and Mozilla have an API and an
> implementation for that. With such an API, there are enough tools to
> build an email application (there is one in Firefox OS), a P2P client,
> an IM client or whatever is needed regarding messaging trough the Internet.

So you suggest there will should be no defined API specifications for
email and IM?
How the developers will be able to send emails and instant messages?
By using 3rd party libraries?

Are you seriously suggesting to implement full protocol stacks in JS???
SIP, XMPP, Skype, etc? How will that interwork with native stacks in
the same device? Port conflicts?
Are you aware that for instance SMS can be delivered via SIP?
Looks like there are implicit assumptions on the targets.
We need to define requirements for these.
The way I see the web platform is a window to the native middleware.
You likely imagine it as a POSIX OS and write from scratch everything.

It should be possible to create products following either approach,
but we need API's that are good enough to cover both.

It is a good approach to start from use cases, and provide mechanisms
to implement the most common UI interactions.
We don't seem to have aligned the use cases, which means there will be
a lot of diverging assumptions, making it very difficult agreeing.

>
> Email is something that was very controversial inside Mozilla at the
> beginning of the project with people requesting an API for it but as far
> as I can tell, there are already specifications (IMAP, POP, SMTP) and
> there is no hardware or system requirements except being able to connect
> to a server which, as said above, will be solved. What should happen is
> libraries like imap.js, smtp.js (or even pop.js for people living in the
> previous decade). We shouldn't bloat the Web Platform.

If reimplementing protocol stacks in JS is not bloating (compared to
10% changes to the API's), I don't know what is.

>
> In my opinion, the main difference with SMS and email (or any other use
> case listed above) is that the former is something that require system
> and hardware requirements. There is no way for a web application to
> access the RIL. In addition, users will expect that two SMS apps will
> access to the same SMS so we need a system-wide storage. Emails already
> have that on the server-side.

I agree.

Regards,
Zoltan


>
> [1] http://www.w3.org/2012/09/sysapps-wg-charter
>
> Cheers,
> --
> Mounir
>

Received on Friday, 26 October 2012 11:15:05 UTC