[minutes] 2020-08-26 WebApp Manifest & MiniApp Manifest Discussion

The minutes of today's WebApp Manifest & MiniApp Manifest Discussion are 
available:
   https://www.w3.org/2020/08/26-manifest-minutes.html

text version below:

WebApp Manifest & MiniApp Manifest Discussion 26 August 2020
Attendees
Present
Anssi, Krchrist, Marcos, plh, wangzitao, xiaoqian, yongjing
Regrets
-
Chair
plh
Scribe
xfq, xiaoqian
Contents
Meeting minutes
<plh> 
https://‌github.com/‌w3c/‌miniapp/‌blob/‌gh-pages/‌specs/‌manifest/‌docs/‌explainer.md#a-miniapp-manifest-comparison-with-web-app-manifest

marcos: I'm going to talk about where we are at Manifest and the longer 
term plan
… we are moving to CR now

… web app manifest has been widely implemented by the major browsers
marcos: we are blocking new feature requests in CR
… no more features added before CR
… doesn't mean we can't develop things in parallel
… we were quite liberal about new features in the beginning, before CR 
we may not want to add things until it work on every browser and every 
UA and developer can use it
… let everyone focus on a CR feature set, we are now focusing on testing 
and implemented details
… manifest requires manual testing
… no fun
… weren't able to automate the tests yet
… identify bugs and interop issues
… quite surprising things like some browser doesn't support the icons
… I won't go into the details
… it's an ongoing process
… that's how we work
… we are open to new idea and love to hear about new use cases
… want to make sure that there's a common base about adding features in 
the spec and the Web

plh: does someone want to speak on the status of the miniapp manifest 
before we go to the list?

marcos: Anything to add, Anssi?

anssi: I've been following the MiniApp discussions
… I've two high level question
… does the miniapp community see value to interop with the web 
ecosystem?
… how people reach that goal?
… two manifests have overlaps

kenneth: the goal from the TAG is not to have two manifest in the web 
ecosystem
… we should know what is the difference, why that happens

yongjing: let me talk about the status of the miniapp manifest
… it's about 80% completed but still room for the development

plh: do you mean it's frozen?

yongjing: not frozen
… we will continue updating the miniapp manifest
… after receiving feedback from the community
… appreciate the effort plh has made

<plh> 
https://‌github.com/‌w3c/‌miniapp/‌blob/‌gh-pages/‌specs/‌manifest/‌docs/‌explainer.md#a-miniapp-manifest-comparison-with-web-app-manifest

yongjing: we can better adapt to the web app manifest editing style

plh: is there desire to adopt some of the stuffs in miniapp manifest?

marcos: I can't predict the future obviously
… but if people come and show us fancy and cool stuffs, and the use 
cases are compelling
… by all means possible
… currently we're focusing on existing features before CR
… we can go through them, also want to figure out whether MiniApp is a 
superset
… if there's sufficient interest there's no reason not to
… especially in the living standard model

… if the Process 2020 allow us to update the CR
anssik: is there any plan for the MiniApp vendors to adapt the other 
webapps specs? if it’s feasible for the use case
… someone who understands miniapps and webapps can answer why web app 
can't solve some problems

yongjing: let me try clarifying the question
… why not reuse the PWA model?
… my personal opinion
… the miniapp runtime, especially packaging, is not interoperable with 
web apps
… miniapp is more like native apps, some MiniApp is like an android APK
… but uses a lot of web technologies, f.ex, js, css...
… the things to be archived in a package is not necessarily a webpage
… not HTTP Exchanges in WPACK
… miniapp doesn't have this kind of requirement
… but how to organize the files as a package
… widgets is another example
… not necessarily HTML5-based components

Marcos: if not HTML5, what's used instead?

yongjing: different technologies in different vendors
… some uses modified version of HTML5, but you can map them into HTML5
… some are not in a web context, for those components not provided in 
low-level they need to be defined
… markup language may not be HTML

plh: an example would be the map component

yongjing: and tabs

anssik: what are the implementation expectation for miniapps? none of 
the current 3 major browser engines, right?

yongjing: for current implementation we have a "super app" model and a 
"quick app" model
… for "super apps" like AliPay, WeChat, miniapps are run in the app 
(NativeApp)
… some of them are based on webviews, some of them are not
… some of them are moving away from webview to a native approach
… more like a Flutter style

anssik: it seems like miniapp is a different thing from the web 
platform, simply using the web APIs may not work

yongjing: we are still in the incubation stage, miniapp vendors are 
still trying to converge with each other
… we welcome the browser vendors to join and explore the possibilities
… one of the ideas is to support browsers as another runtime
… we have a meeting in the CG this evening to discuss the runtime 
question
… to see if it's possible to modify the browser runtime to support 
miniapps
… or to include another engine in a browser to support miniapps
… happy to explore this possibility
… the main contributors of miniapps don't have a consensus on this yet

anssik: it's a more feasible goal to reach interoperability among 
different miniapp vendors first
… interoperability between web and miniapps can be very challenging from 
my experience, the Web has such a long history
… thanks for your explanations
… it's much clearer to me now

yongjing: for some individual technologies, like manifest
… we can try our best to align as much as possible, so that it will be 
easier for the developers use the APIs

anssik: if that’s the incentive, it’s clearer to me, if some pieces are 
possible then it can be helpful to developers
… like make porting web apps to miniapps easier
… my limited understanding on miniapps

yongjing: agree with you, this is one of the use cases we've been 
exploring
… some developers are porting from web apps to miniapps

plh:agree, we can make the job easier for developers
… converge between web apps and miniapps, some part of the runtimes can 
be different, but there are overlaps in the use cases
… and it will also be beneficial to converge among different miniapp 
platforms

marcosc: agree, if there's interesting things that would benefit the web 
platform
… that's tremendously useful for both
… as anssik said, incrementally improve what's already there is the 
current model of the web platform
… given we have millions of millions of web apps out there

… for example the new components, we want hear what the are
… if miniapps are to fill in the holes of the Web, we want to hear what 
the holes are
… maybe there are reasons for the holes, we need to find new ways to fix 
them
marcosc: we're trying to force the community to finish the first phase 
of web app manifest
… but still open to new features
… after the first phase

<plh> 
https://‌github.com/‌w3c/‌manifest/‌issues?q=is%3Aissue+is%3Aopen+label%3A%22Feature+Request%22

yongjing: what's the plan after the first phase? start working on 
another new version?

marcosc: I don't expect much delay after the first phase

anssik: after process 2020 it's easier to add new features after the CR, 
we will quickly go to the next version

yongjing: so the new ones dont need to wait until V1 moves the REC
marcosc: we will triage and pick some of those most exciting new 
features, adding new features is not only a challenge from the w3c 
process
… but a challenge to persuade the browser vendors/UAs the feature is a 
good idea to actually be implemented

plh: I put a link on irc
… on the feature requests

<plh> https://‌github.com/‌w3c/‌manifest/‌issues/‌804

plh: how we can converge on this example issue ^

anssik: we want the vendors to implement the base first, after that we 
can ship new feature much faster. Go back to miniapp environment...
… is it a reasonable goal to transition between web and miniapps
… if so we should make it clear in the charter
… this is a side comment
… if we have two different manifests in REC-track
… the 500 membership will ask questions, if the goal is allow easier 
adaption...

yongjing: happy to add that to the charter

anssik: some personal experience, I've been charing the DAS WG for a 
while
… in that group we have connections with cordova/phonegap
… not 100% converge with them
… for example there are APIs for accessing sensors in cordova, we do the 
experiments first, and then see if it can be brought to the Web for 
wider adaption
… MiniApp can have similar working mode and feed those use cases and 
requirements back to the web and see if web can solve them

plh: doing an extension would work but in the future there is a risk, if 
some of the basic APIs are different

marcosc: where things can align they should align

plh: the description of window is the most pressing one now

marcosc: if it’s not too late, miniapp manifest can have a miniapp 
properties
… all miniapp-related properties can go into that category
… like a namespace

yongjing: one question
… I read through the web app manifest
… is there any text on which properties are optional
… or all of them are optional?

marcosc: all of them are optional

yongjing: kind of worry that the mandatory properties are different, in 
MiniApp some are required

marcosc: it come from the different base environment of the UAs, as long 
as they work… you can still install the app even some of these members 
don’t work

plh: regarding permissions
… requesting Permission still under development in MiniApp
… what about web app manifest? any similar discussion?

marcosc: incompatible with the web's permissions model
… permission prompt when used
… we also have Permissions Policy

plh: upfront is not possible?

marcosc: we had a few past discussions, the problem is it can't be 
compliant with the Permission model of the web, unless something like 
Permissions Policy
… basically everything is allowed unless you disable it

plh: what's the use case for miniapps?

yongjing: most current miniapp implementations have permissions control, 
miniapp touches low level apis, people need to take case of the 
permission more carefully, it’s required to give permission to manifest 
before installation.
… in many cases you need to get a user consent
… before delivering the miniapp to the user

marcosc: that's fundamentally incompatible with web platform
… also incompatible with iOS
… iOS has a control model similar to the web
… Android is moving to a more user control model

plh: next step is to keep iterating the miniapp manifest spec
… not based on my pull request, which can be dropped
… do we need to raise feature request to web app manifest repo?

marcosc: yes, please! we would like to hear about MiniApp, the more we 
share, the better

yongjing: how do we do that from a logistics perspective?
… fequently reporting the updates?

marcosc: we can also catch up every 3-6 months

yongjing: happy to, when we have a compatible version of manifest
… we'll keep you posted

plh: thank you everyone for attending the call, I call that progress :)
… can organize another call when we have a compatible version of 
manifest

[adjourned]

Received on Wednesday, 26 August 2020 14:20:13 UTC