Name: Mozilla Apps 生態系統的架構 - 第 1 部分 - 系統與概念 (Architecture of the Mozilla Apps Ecosystem - Part 1 - Systems & Concepts)
Uploaded: 2021-01-14T04:45:52.000Z
Duration: 7 min 43 s
Description: 【看影片學英語】數萬部 YouTube 影片，搭配英漢字典即點即查，輕鬆掌握單字發音與用法，長久累積看電影不必再看字幕。

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

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

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

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

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

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

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

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

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

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

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

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

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.