Prepared for the MiniApp Virtual Meeting 2020, July 30-31

Video hosted by Web Castor on their StreamFizz platform.

Transcript

Hello, everyone.

I'm Yongjing Zhang from Huawei.

Now I'm going to introduce to you the two technical parts in MiniApp that we've been discussing: Packaging and Manifest.

First of all, MiniApp Packaging is in fact a packaging technology.

As we've discussed in the community group, we'll use ZIP file as its format.

Its main purpose is to put all the files and resources a MiniApp needs into one single package.

This package can be delivered to a hosting platform which is our user agent in various ways or through various channels.

As for how to deliver, we haven't defined the details yet.

But once this package gets to the user agent, it will be processed by the hosting platform and then excuted accordingly.

This package includes several parts as follows.

The first thing is a JSON-based file called manifest.json which is responsible for the global configuration of the Manifest.

The second one is app.js.

It's quite important to the MiniApp processing.

This JS file is the main application entrance of the MiniApp and is also in charge of lifecycle management.

The third one is app.css which defines the default style of the MiniApp.

The fourth one is a pages directory which contains multiple page-related files of the MiniApp.

It may include 4 types of files.

For every page, there's a main app logic which is a .js file.

At the same time, some files are for the page layout.

Right now what we see here is .xml, but we're still discussing about how to specify it.

It might not entirely be an XML file.

There're configuration files in the format .json for each page as well as style pages .css.

Since a MiniApp could have multiple pages, the pages could be organized in different sub-directories and of course in a flat manner as well.

There're no specific rules for this yet.

We think developers can make their own decision according to user preferences.

Besides, there's a common directory which contains common resources including images, scripts, reusable UI components and layout templates.

These resources can be used by one or multiple pages.

These pages also include widgets and we might cover that a bit later.

Same with the pages, these resources can be organised by sub-directories.

But more related details including some of the components we see here, I mean more detailed definition of its components or widgets still needs to be further discussed.

There're no specific rules yet.

The last one, as you can see, is i18n which is a directory for internationalization.

This directory contains multi-language configuration files, as a MiniApp might be used and installed in multiple areas.

So for different areas, developers can have different configurations, like configuring or replacing certain strings.

Detailed specification is still being discussed.

We'll talk about them more in detail later.

As for the security consideration of the MiniApp package, one important issue is that we think the package needs a complete digital signature system to ensure its integrity and trustworthiness.

The details are still under discussion in the MiniApp CG. Processing the MiniApp package can be divided into these 5 steps.

Actually we've already seen this in the initial MiniApp introduction.

To begin with, we get a package through different channels.

This is the Archive file, which we'll name as .ma file for now.

This file is delivered by one of the many channels, then the user agent needs to verify this MiniApp package thoroughly.

The most important part is digital signatures, which is to ensure that the package comes from a trusted author or a trusted distributor like an application store or a GitHub.

Also, we need to be sure that the package isn't tampered during delivery.

When we're certain that the package is complete, we need to handle the files it contains.

The first thing to look at is the Manifest file, from which we can learn the platform compatibility information installing a MiniApp requires.

Then we can check platform compatibility as well as permission to use relevant applications.

We can also get default UI style and some other information regarding the page.

After this, user agent can prepare the runtime environment including the logic layer and view layer.

Then the MiniApp gets installed.

This installation requires two entrance.

The first one is app.js, the main logic entrance.

The second one is the startup page.

We can see this startup page in the introduction of Manifest.

During our work on this MiniApp Packaging specification, we've also researched into some previous packaging technologies and standards, as well as some that are still under development.

We did some comparison.

Our goal is to see if MiniApp packaging can merge with or learn from these previous technologies or the ones that are still under development.

We've compared the aspects of supporting client platform, content of the package, web dependency, file format and digital signature technology.

For now, it seems that we can't directly use other technologies on MiniApp packaging.

The main difference is that although MiniApp leverages many popular Web technologies like JS, CSS, the content of the package is more like a native mobile app rather than a web page of a snapshot of a web-content collection.

For example, WPACK technology takes into consideration of Web content exchanges like information regarding HTTP request and response.

So there're a lot of HTTP-specific designs like HTTP header extension and its CBOR-based format.

We think that these features are not suitable for MiniApp.

Another technology which is a bit older is WebPackage.

It's actually quite similar to WPACK.

The difference is that it uses a special format called Streamable Package Format which is an obsoleted technology.

For now, it presents the similar problems.

The design is based on some special conditions or requirements of HTTP.

On top of those, there's an even older technology called Widgets which is a W3C standard.

It has some similarities to MiniApp as it also doesn't fully depend on web service or websites, and it can install some local applications.

But this technology was created a long time ago so the security mechanism it uses like XML-based configuration might mean higher security risk.

That's why we think it doesn't fit MiniApp.

Another standard that's under development is LPF, a lightweight packaging technology.

This is mainly for some digital publications, and the specification is not complete yet.

For example, the digital signature hasn't be properly defined yet.

Considering this, it might not fit MiniApp either.

This is the comparison between packaging technologies.

More details can be found in the explainer.

The manifest file in MiniApp Packaging is quite important, so we've created a specification just for it.

It includes information and definition of attributes.

The configuration file contains these following parts: some basic metadata about the MiniApp like its App name description, language tag and so on.

The second one is version control of the MiniApp like some version information of the app itself as well as the minimum supported version of the required client platform.

The third one is the MiniApp's configuration of page routing and window style.

Since MiniApp is not a pure Web application, its interface needs more specific description or configuration to ensure the consistent user experience between different pages.

That's why we have a configuration file like this.

The last part is some configuration information.

Of course, this specification Oh, sorry, I mean permission declaration.

This is because that MiniApp depend on some client platforms or some special data provided by native OS.

There might be sensitive data of users like their contacts or geolocation, or the terminal's hardware capacity information like the camera capacity or some special API access.

So we have some strict permission control policy here.

There's an example on the right for your reference.

While we work on the specification of MiniApp Manifest, we also analyzed some other relevant technologies.

We found that Web App Manifest is a pretty similar one.

So here, in this table, we've done a comparison.

Some parts are actually common.

For example, an application contains basic information, description of metadata, name, icon, language and so on.

Regarding this, we have a lot in common with Web App Manifest.

Only some attributes are named differently.

Maybe we can align them later on Besides, Web App Manifest has a lot more configuration which hasn't been discussed in detail in our MiniApp community group so far.

But personally I think many of the configuration can be used on MiniApp.

The main differences are in three aspects: platform, permission and application components.

As I've mentioned earlier, MiniApp is more similar to a native App rather than a Web App, so its runtime environment doesn't fully depend on browsers or technology like HTML5 which is different from underneath technology Its hosting platform compatibility is an important factor to be think about.

Like what we talked about at the beginning, some platforms are based on Super App, and some are based on Native OS. In order to run on different platforms the version compatibility is very important, so we need Manifest to configure it.

Next, as we mentioned earlier, is that it requires strict permission control policy when accessing user data or calling API.

The last one is the configuration of windows and page routing of the whole page, which are specific to MiniApp.

So we need to have some more extensions here.

As for whether we can eventually merge with Web App Manifest, we'll continue to discuss it in this group later on.

And surely we'd like some communication with Web App Manifest.

So this is the presentation of my part.

Thank you.