

Introducing WebAPI - sylvinus
http://hacks.mozilla.org/2011/08/introducing-webapi/

======
dave1010uk
It would be great if Mozilla worked with PhoneGap on this as they already have
APIs [1] that cover most of these and have pretty good cross-platform support
already [2].

[1] <http://docs.phonegap.com/>

[2] <http://www.phonegap.com/about/features>

~~~
ristretto
Agree to that. However, given that webkit is the widely used mobile browser,
the webkit project should implement something similar asap. This covers a real
need and its actually kind of baffling why we still don't have those simple
apis in the browser already. Given that both big webkit contributors, apple
and google, have vested interests in non-browser mobile apps, it's not
surprising.

~~~
kalleboo
Google have a vested interest in non-browser apps? What? Why does ChromeOS
exist then?

~~~
ristretto
I believe as long as iOS exists, google will be pushing Android to assert
their dominance. I guess that's why they still don't really push chromeOS. (Do
any chromeos laptops exist?)

~~~
sciurus
There are models from Samsung and Acer.

<http://www.google.com/chromebook/>

------
dotBen
As much as I support what they are doing, I don't see Apple implementing any
of this any time soon - even if it is in the Webkit trunk, they'll just rip it
out/deactivate it.

Apple's strategy for their phone platform runs deeper then just what is in the
open source Webkit codebase.

I used to think/hope open platforms would ultimately win in the market but iOS
and the Apple App Store has kind of proved otherwise.

~~~
sjs
Why not? They pioneered all the techniques they use for using web apps like
native apps on iOS, such as adding them to the home screen. I don't think
there's any evidence that supports your argument whatsoever.

If people want to run web apps on iOS devices Apples is more than happy to
sell them for that purpose.

~~~
cgislason
I agree, unless someone can point to anything Apple has ripped out or
deactivated in WebKit. Apple seems to have been pretty open with Mobile
Safari.

The most closed thing I can think of is when they only enabled their faster JS
engine for the browser itself and not for apps. The next major release changed
that, and it is not related to WebKit itself.

~~~
lukifer
Nitro is enabled in iOS for web apps added to the home screen, but not
UIWebViews (aka, PhoneGap). While I don't think it's actively sinister, it
doesn't seem like they're going out of their way to correct it, either.

~~~
henrikhansen
The problem is that they can't allow programs to execute parts of the memory
as instructions. This is needed for efficient JITs like the one in Nitro.

Apple is actively (Frequent commits) working on fixing this problem. The
project is called Webkit2, and features a Javascript interpreter that runs in
a separate process, and thus is able to safely execute Javascript on iOS. This
model, btw., is inspired by the multi-process architecture found in other
major browsers.

------
Sembiance
Sums this up nicely: <http://xkcd.com/927/>

------
coderdude
>>Mozilla would like to introduce WebAPI with the goal to provide a basic
HTML5 phone experience within 3 to 6 months. [...] Specification drafts and
implementation prototypes will be available, and it will be submitted to W3C
for standardization.

3 to 6 months is a fairly short timeline for getting all browser vendors and
the W3C on board, not to mention getting stable and secure implementations
into the wild. At least they're doing all the legwork by putting together the
initial specification drafts and implementation prototypes. These additions
would be truly incredible if accepted. I know they like to lump every standard
under HTML5 these days so I wonder if this is intended to be an addition to
that or if WebAPI is completely orthogonal to HTML5.

~~~
nl
_3 to 6 months is a fairly short timeline for getting all browser vendors and
the W3C on board_

As far as the specs go, most of the things they list have W3C APIs at
reasonably advanced stages. I keep track (somewhat) of the Camera APIs, and
they are at a point where Opera has an experimental implementation on Android,
and Ericsson has a Webkit version with some support.

The implementation is more tricky. They can fix Firefox on Android of course,
but in theory they could pay people to work on Webkit to help out iOS users
(and the default Android browser). I'm not sure what Mozilla sees as their
vision: is it to create the best web browser on the planet, or is it to make
the web platform as good as it could be?

I don't see how they could help Microsoft out with their implementation
though.

~~~
starwed
Mozilla does have an explicit mission statement.

> _Mozilla's mission is to promote openness, innovation and opportunity on the
> web._

<http://www.mozilla.org/about/mission.html>

<http://www.mozilla.org/about/manifesto>

------
robjohnson
I think the biggest issue is that you would need to get buy-in from the major
manufacturers and it doesn't seem to be in their best interest. The further
divergence of the platforms, in tandem with the conscious raising of switching
costs, is one of their main strategies.

------
MatthewPhillips
Here's the bug for Telephony:
<https://bugzilla.mozilla.org/show_bug.cgi?id=674726>

------
mkramlich
good idea. horrible name.

------
CGamesPlay
This appears to be very close to a direct competing standard (standard
proposal) with Google's WebIntents:

<http://webintents.org/>

[http://blog.chromium.org/2011/08/connecting-web-apps-with-
we...](http://blog.chromium.org/2011/08/connecting-web-apps-with-web-
intents.html)

~~~
MatthewPhillips
1) It's not "Google's WebIntents", both Google and Mozilla are working on the
project _together_ [1], after coming up with the same idea separately at
first.

2) This doesn't compete with WebIntents, which is about application selection.
WebAPI is about device integration which is _compatible_ with WebIntents. You
could, for example, want to make a call and be prompted with several Phone app
choices (thanks to WebIntents) and then dial the number and make the call
(thank to the Telephony API which is part of WebAPI).

[1][http://www.readwriteweb.com/archives/chrome_and_firefox_work...](http://www.readwriteweb.com/archives/chrome_and_firefox_working_together_to_make_web_ap.php)

------
drivebyacct2
I would prefer that Contacts where not an API and just a user created/chosen
web app. Why is there a need for a Contact API?

On a separate note, should someone be starting up a OMA push proxy for SSE? I
have a feeling that between Chrome getting an Android port, the Moz/Chrome
WebRTC and Moz's Web APIs, that Server Side Events are going to become "a
thing" and OMA push proxy would be a useful service.

~~~
tbassetto
To provide a convenient way to select friends.

~~~
drivebyacct2
But how does a system level Contacts API make any sense when Web Intents and
any-old-body's webapp exists?

I guess I may be thinking about it incorrectly. If this is for web apps to
implement a common standard of functionality across Contact "apps", then this
makes sense. Otherwise, why are we falling back to "native" when it comes to
Contacts, especially when modern contacts exist as part of an online profile -
Google Contacts, Facebook Friends and Twitter accounts I follow compose my
entire "Contact List".

~~~
MatthewPhillips
You're forgetting SIM cards which contain contact information. People want to
be able to start their phone app and have contacts already there. Then they
can link to Google or Yahoo or whatever else to import more.

Also remember that this isn't just part of B2G. This is functionality that
will be rolled into Fennec. So when you open your contacts web app in Fennec
on Android you should have the same contacts that the native contacts app has.

~~~
fpgeek
Exactly. The point of the Contacts API isn't to replace existing contacts web
apps, it is to make them better by giving them access to native contacts (and
potentially other contacts sources).

~~~
drivebyacct2
My point is that "native contacts" should be irrelevant soon.

------
mgutz
It would be great if Mozilla followed through on their projects. Prism to
Chromeless to stalled. Chromeless has potential to expand their core product,
which is the browser. Why does everyone have the need to be Google and have
their hands in everything?

------
BrandonSmith
Frankly, this is Mozilla's reaction to Google's <http://www.webrtc.org/>

To put it in perspective, Mozilla has no mobile platform and is crying for
relevance.

Apple -> iOS/WebKit Google -> Android/WebKit Mozilla -> ???/Fennec

By getting desktop browsers to implement telephony and other collaboration
APIs, I'm sure their hope is to get mobile browsers to likewise expose the
precious voice and video APIs of the mobile handsets. And perhaps by doing
this, lines between browsers on mobile devices are blurred to where Fennec has
a role.

~~~
FrankBooth
WebRTC is a realtime voice/video communications API, and Mozilla are working
with Google on shipping an implementation.

Frankly, your tone is trollish.

~~~
BrandonSmith
You're right. It did come off trollish. Wasn't my intent. I'm sorry to both
parties.

Both WebAPI and WebRTC will produce awesome collaboration apps. Wins all
around.

But how, exactly, do the two fit together? Is WebRTC a low-level
implementation of protocols, codecs, and transports whereas WebAPI provide the
friendly developer-oriented APIs?

Will WebAPI provide hooks for standard widgets for dialer, SMS, contacts, etc?

~~~
MatthewPhillips
> But how, exactly, do the two fit together? Is WebRTC a low-level
> implementation of protocols, codecs, and transports whereas WebAPI provide
> the friendly developer-oriented APIs?

They're not related. WebRTC is a video chat/conferencing project.

> Will WebAPI provide hooks for standard widgets for dialer, SMS, contacts,
> etc?

Yes, that's its precise purpose.

~~~
hrabago
> > Will WebAPI provide hooks for standard widgets for dialer, SMS, contacts,
> etc? > Yes, that's its precise purpose.

I'm not seeing any indication that standard widgets are even in their goals.
For instance, their Telephony API [1] lists functions that an application
implementing its own UI might call, but nothing that indicates that those are
UI widgets or expose UI-like functionalities.

[1] <https://bugzilla.mozilla.org/show_bug.cgi?id=674726>

~~~
MatthewPhillips
Well, this is WebAPI after all, not WebUI... but why do you think they should
implement UI widgets? That goes against the grain of the web.

~~~
hrabago
_I_ don't think they should. In fact I hope they don't.

