Meeting minutes
marcos: I'm going to talk about where we are at Manifest and the longer term plan
… we are moving to CR now
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
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
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
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]