Re: [w3ctag/design-reviews] MiniApp URI Scheme (#478)

Hi, Cynthia,  If I had misunderstood your question, please tell me.

I understand your question contains two points,

1. Why not directly use the HTTPS protocol as the MiniApp URI?
2. The current MiniApp URI mechanism requires a set of runtimes to parse it. Why is it necessary? What is the difference between that runtime and a conventional browser?

For point 1, downloading a package through the network is just one of the ways to get a package. In addition, there are many ways to access a miniapp resource:

For example, after accessing the miniapp once, the miniapp package would be stored locally. Or the user agent can preset the miniapp package before the user accesses the URI for performance (as we mentioned in [#2.1.6 of the miniapp white paper](https://w3c.github.io/miniapp/white-paper/#performance-and-user-experience) ). Or when debugging the miniapp, the developer can directly push the miniapp package to the user agent through a debugging tool.

In these cases, the user agent open miniapp locally according to the appId in MiniApp URI without having to request a package server.

In other case, the user agent can specific its own mapping relationship with "host" component. For example, the "bar" in "miniapp: // foo @ bar" can correspond a domain or a local directory, anyway.

In summary, MiniApp URI are designed to locate MiniApp resource cross-platform, regardless of how they are obtained.That cannot be expressed intuitively through HTTPS URLs only. This is why we mentioned in [Chapter 6 Use HTTPS](https://w3c.github.io/miniapp/specs/uri/#https) that it is non-normative, and it just describes a user scenario.

For point 2, the runtime make miniapp can help to fill the gap of the Web and the Native.(like we mentioned in [miniapp white paper introduction](https://w3c.github.io/miniapp/white-paper/#what-is-miniapp). And because the design of the MiniApp is different from traditional web applications (like we mentioned in [the core-features the miniapp white paper)](https://w3c.github.io/miniapp/white-paper/#core-features)). Even if the miniapp packaged is downloaded by a traditional browser, it cannot be opened and run.

And with the necessity of the MiniApp URI demonstrated above, therefore, browsers need to implement MiniApp URI specifications to correctly parse MiniApp URIs and implement MiniApp runtime related specifications (under development) to open and run MiniApps properly.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/478#issuecomment-593195204