W3C home > Mailing lists > Public > public-sysapps@w3.org > October 2012

RE: Messaging - SMS API draft

Date: Fri, 26 Oct 2012 12:33:14 +0000
To: "Kis, Zoltan" <zoltan.kis@intel.com>, Mounir Lamouri <mounir@lamouri.fr>
Cc: "public-sysapps@w3.org" <public-sysapps@w3.org>
Message-id: <A52BC7FE998B7E43BB74213DE5CD3690055CC34A@EX10-MB2-MAD.hi.inet>
On 26 oct 2012 at 13:14:35, Kis, Zoltan wrote:
> 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).

Though MMS and SMS could live as separate APIs I agree that they can be combined in a single API and probably it is the best solution.

However I strongly disagree that MMS and email are the same case. The interface between the MMS client and the MMS Server is MM1, which is not SMTP but HTTP + WAP Push. MMS cannot be built just making use of an internet connection as it requires the reception of WAP Push notifications and because MNO may require the use of an specific APN for MMS.

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


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:

Received on Friday, 26 October 2012 12:33:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:36:10 UTC