Placeholder Image

字幕表 動画を再生する

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

My name is Bill Walker, I'm an engineering manager in the Mozilla Apps program. Today

字幕と単語

ワンタップで英和辞典検索 単語をクリックすると、意味が表示されます

B1 中級

Mozilla Apps エコシステムのアーキテクチャ - パート 1 - システムとコンセプト (Architecture of the Mozilla Apps Ecosystem - Part 1 - Systems & Concepts)

  • 23 3
    陳彥良 に公開 2021 年 01 月 14 日
動画の中の単語