search

w3c / miniapp-addressing

MiniApp Addressing
https://w3c.github.io/miniapp-addressing/
Other
5 stars 5 forks source link

update uri scheme to addressing #4

Closed Sharonzd closed 2 years ago

Sharonzd commented 3 years ago

Changelog:

  1. modify the core concept MiniApp URI scheme to MiniApp Addressing, which aims to describe how to addressing the MiniApp resource
  2. introduced mobile deep linking technology, and supports two ways: custom-scheme and https://host

Preview | Diff

zhangyongjing commented 3 years ago

Thanks for the update. It seems to need a bit more refinement:

  1. There are 2 addressing solutions proposed: 1) custom-scheme (deeplink-alike); 2) https scheme (applink-alike). It's better to clarify how these 2 different solutions would be used, and in which circumstance. It would also be useful to refer to deeplink and applink and explain the different behaviors, if it's the intention.
  2. I doubt if the 'custom-scheme' would be acceptable by those who were against the previous miniapp:// scheme proposal. To me, the miniapp:// scheme is a just specialized 'custom-scheme' (or deeplink). Leaving 'custom-scheme' as unspecified doesn't seem to address the concerns. (That said, I'm personally OK with deeplink-alike approach, which has been widely used by many MiniApp platforms.)
  3. The changes in this PR are not complete/consistent. For example:
    • The host part follows immediately after the scheme comparing to the previous version where a @ prefix is used for the host. But @ is still used in the examples.
    • In section 4.1, there are some copy-paste issues regarding "id".
    • miniapp:// scheme is still used in section 5 and 6.
Sharonzd commented 3 years ago

@zhangyongjing Thanks for your comments! As to point 1 and point 2, I will explain more. Regarding point 3, sorry for the uncompleted status, I have fixed it.

Sharonzd commented 2 years ago

Considering some frequently asked questions online and offline. I would like to add some explanation about this pull request.

Q1. Why did you change the MiniApp URI scheme to the MiniApp Addressing ? A1. This modification is the result of the discussion in issue No.2. The conclusion is that we shouldn't specify a new scheme( miniapp:// ), but rather reuse the HTTP scheme (https://), and define a technical solution just like the deep-link. See https://github.com/w3c/miniapp-addressing/issues/2 for more information

Q2. Why does this include 2 solutions? Why do we need custom-scheme? A2. Because custom-scheme is more compatible with different operating systems. It can run on more systems and devices, and it is also compatible with the existing implementations mechanism(We want the MiniApp vendor to implement this note faster and more securely).

Deep-link technology also contains 2 ways, custom scheme, and HTTP.

For Android, they are called deep-link and app-link respectively. For iOS, there is universal link and custom URL scheme.

MiniApp also needs to support both, custom-scheme(like Android deeplink and iOS custom url scheme) and HTTP scheme (like Android applink and iOS universal link).

We prefer user agents to implement HTTP schemes, but custom-scheme is also necessary to appear in this note.

Q3. Why did we specify that 'miniapp' must be included in the URI as uri-infix? A3. Unifying the URI syntax of the Minapp, and identifying the URI as the MiniApp URI, which can give developers and users a constant understanding.

Different user agents need to register different schemes (platform://) or HTTP URI prefix(https://platform) in the operating system, so it can’t express the Miniapp character. A more appropriate way is to use 'miniapp' as the Miniapp character in uri-infix.

Q4. Can user agent(or browser) identify other’s MiniApp URI? A4. If the user agent can handle that URI correctly(dereference the URI, download the package, provide runtime, render, and so on) with the standard method, then it can identify other's MiniApp URI and show the corresponding Miniapp. If it can’t, it should open the user agent(or app) which can handle the URI, similar to deep-link.

The ideal situation is that any user agent can handle any MiniApp URI, even if the package comes from a different user agent source. That’s what we are doing at CG and WG, standardizing the MiniApp.

But there is not a unified origin for distributing MiniApps nowadays. MiniApps are managed by package servers of different user agents. And user agents usually don’t allow others to download their packages. So at this stage, it is probably more likely that the user agent open another user agent to handle the others' MiniApp URI.

We hope different vendors can establish a trust mechanism and make packages that can be fetched by each other, just like web app is for browsers.

We can have more discussion about this topic in the MiniApp Packaging Spec.

xfq commented 2 years ago

Merging per https://www.w3.org/2022/01/20-miniapp-minutes.html#t04

xfq commented 2 years ago

Thank you all for your efforts!