Re: Messaging - SMS API draft

On 26/10/12 12:14, Kis, Zoltan wrote:
>> 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?

Yes. Or by writing their own implementation.

> Are you seriously suggesting to implement full protocol stacks in JS???

Yes. Mozilla wrote a PDF reader in JS [1] and is working on a Flash
interpreter in JS [2]. There are also games written in JS [3]. I do not
see why handling protocol is harder than those projects.

FWIW, InstantBird is implementing all its protocols in JS [4] but, to be
fair, it is using Mozilla APIs (trough XPCOM) to access anything that
requires privileges (like socket). I would say that a goal of this
working group would be to make InstantBird doable without using
Mozilla's stack but using regular Web APIs.

> SIP, XMPP, Skype, etc? How will that interwork with native stacks in
> the same device? Port conflicts?

I can have multiple email clients on my laptop and each of them have
their own way to access my emails. I do not understand why it would be a
problem here.

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

I think we should only include in the Web Platform stuff that can't be
done using Javascript nowadays. Mainly, because Javascript can't access
some resources (like raw sockets or RIL on a phone). In addition to
that, there are performance reasons: some stuff are so performance
sensitive that we need a native implementation because JS can't be as fast.

I indeed, do not see the Web Platform as a middleware, developers can
just write their middleware.

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

Indeed. We should probably try to agree on use cases.

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

I see a huge difference between those two situations. Writing a full
protocal stack in JS is hard, sure but you can do it once. Someone can
write it and from there, anyone can re-use it and any browser
implementing the basic APIs will be just working. You could even imagine
using emscripten to do so.

Requiring all browsers to implement XMPP, SIP, IMAP, SMTP, POP (and so
on...) will make the task harder for all browser implementations and
incredibly raise the bar to be "Web-compatible". Also, it will create
situations where an application will work because browser A has a full
implementation of a few protocols but browser B doesn't have everything
yet and browser C has nothing so the application will have a
inconsistent behaviour.

[1] https://github.com/mozilla/pdf.js
[2] https://github.com/mozilla/shumway
[3] https://github.com/kripken/BananaBread (you can try it here:
https://developer.mozilla.org/demos/detail/bananabread/launch)
[4] http://hg.instantbird.org/instantbird/file/57e31684fa1c/chat/protocols

Cheers,
--
Mounir

Received on Thursday, 15 November 2012 13:35:45 UTC