My name is Bill Walker, I'm an engineering manager in the Mozilla Apps program.
Today I'd like to talk to you about the architecture of the ecosystem we're building here at Mozilla.
I'm hoping that you'll learn what the value is we bring to users and to developers.
I'll try to define the systems and concepts that underlie our ecosystem.
I'll show you how the data flows between our systems, and I'll consider what challenges
we face as the ecosystem grows and evolves.
Next I'd like to talk about the value that we bring to our users and developers.
AS a user, I want to buy my apps once and run them everywhere on all my devices.
I want a consistent identity so that I'm always me across all the carriers, networks and devices
I use.
I want to be able to discover apps in many different ways: in an app store, through a
self-publisher, or maybe through a recommendation engine.
I want to back up the receipts to all of my apps in one place that's accessible and tied
to my identity.
And I want to manage all those apps across all my devices, in a centralized way that's
convenient.
What value we bring to developers is that we allow them to code to one platform, and
optimize to all the devices they want to target.
Developers know that they can discover and buy and install apps on all their devices,
and that developers can innnovate without hitting arbitrary restrictions imposed by
a walled garden.
We allow developers to submit and manage apps programmatically, and we provide them access
to great development tools.
And we give them access to analytics to show them how their app is being used and by whom.
Here's a look at the basic systems and concepts that underlie our ecosystem.
On the left we have the Persona identity service, then we see the back end for an application,
discovery and access to the application, the apps in the cloud server, which gives backup
of receipts and then a payment provider that handles payment transactions with the user.
There are two concepts here in green, the manifest for the app and the app package which
we'll discuss in a few minutes.
There are different kinds of interactions between these items, during discovery we have
communication between the device and the app store.
In the course of identifying the user, communication goes between the device, persona, the app
store and the apps in the cloud server.
During payment flow, the device interacts with the payment provider and the app store
and probably the back-end of the application.
And this causes receipts to be generated, signed, installed on the device and backed
up to the apps in the cloud server.
During installation the device will access the application's backend to retrieve a manifest
or will download a package from the app store.
Both of these will be installed on the device.
When the app is launched, the application on the device may communicate with the application's
backend to verify receipts or to retrieve content.
And during the management phase, apps in the cloud service will interact with the device
to provide access to manifests, receipts and packages from all the apps that have been
installed previously, on any device associated with that user.
So those are the different kinds of ways that the systems in the ecosystem interact with
one another.
Now let's look at the concepts behind those systems in more detail.
For example, What is an Application.
Users don't really care primarily about the technology underneath all this.
What they care about is an experience.
And we want them to have a native application experience that's built with HTML.
That's the fundamental way I think of an application.
You can also say it is a collection of web content that is reachable from a URL within
a particular origin.
I think it's important that an HTML application is very much like the web, except that it
works great offline.
And that's a challenge for many of our web developers today.
it also serves as a context for in-app payments, so that the user can interact directly with
the developer and purchase digital content for a game or subscriptions for a content
site like a magazine or a newspaper.
An application is not a bookmark.
An application is not a tab.
An application is not a website.
It needs to be more than these things.
It needs to behave great offline.
It needs to give the user a native application feeling on every platform where it's available.
Our application is defined by a manifest which gives a set of metadata about the developer
and the application, its icon and so forth.
It enumerates the list of sensitive APIs that the application intends to use.
Here's an example:
We are defining a standard for this that we hope to submit to W3C which will provide a
chance for other parties to participate in the use of this manifest.
Here's a list of the different APIs that an application can request access to.
Most of these will be first developed and used on the boot to gecko phone project.
They include access to Bluetooth, access to the camera, to contacts, to information about
the battery and so forth.
We've arranged access into these APIs into a security model with 3 tiers.
At the highest security level we have certified apps, which are pre-loaded on the phone and
have access to any of these APIs.
This could be for something like the phone dialer or the contacts application on the
phone, critical to the phone's operation.
The next tier, privileged apps, can be written by 3rd parties and are offered in the store.
They are code-reviewed, signed and created as packages and downloaded to the phone.
The least sensitive tier of apps are simply web applications, which can be hosted anywhere,
and which do not enjoy access to these privileged APIs
On the other hand they can be updated constantly, and are not required to go through a code
review on every change that they submit.
Let's talk a little bit about hosting.
Who should host their own application and the fundamental answer is that our users neither
know nor care.
They should have a great experience of your application regardless of where it is hosted.
A developer is free to host an application that doesn't need access
to sensitive APIs.