现场纪要
按照议程我们将进行MiniApp工作组的会议。
安勍：因为今天的会议在中国召开，所以主要还是用中文交流。
按照之前讨论的顺序。按照第一个顺序，第一个是Lifecycle。这正好是我来主导讨论。
今天主要是讨论Issues和contributor。
按照W3C的规则，要进行一些审核，他们有一些反馈意见，今天正好可以花一点时间讨论一下。
https://github.com/w3c/miniapp-lifecycle/issues/30
第一个是关于callbacks。其实它的核心意思是建议不要采用callbacks的形式，还是通过加listing event的方式。
简单介绍一下Lifecycle，对小程序都有页面和触发事件管理，这里是生命周期想做的事情。
所以，它的核心还是定义两部分。一是全局的MiniApp的生命周期。原来是通过callback的形式，后来建议是参考现在W3C里很多通行的做法，改成增加event handler的形式去做。实际用的时候就是通过监听事件的形式，后来做了一些改动。
后来我看了一下，发现W3C包括之前Google做的针对网页的Page Lifecycle，还有Page Visibility的方法。今天人也比较多，看一下这种方法，这也是国内比较接受的一种做法。
调一个例子出来可能更方便看。
Google也是用visibility，实际应用的时候是通过事件监听方式，加上对应的生命周期事件。如果出现了事件状态的变化，触发之后可以进入下一步，通过function触发下一步动作，具体用的时候是这样的方式。
看看现场和线上大家有没有什么想法？可能这里比较仓促，之前很多人没有看过。
之前我和小米的同事聊了，这是相对比较常规的做法。
与会者：但是，这和现在的小程序差别就比较大了。之前是callback，现在小程序无论是全局还是部分，都是onplot（音）。既然你想添加事件的形式，那这个at listing的方式怎么做呢？
就是除了标准，再往下考虑一点落地层面的东西，你写的这行代码，假如一个小程序的开发者，想得到hidden（音）。
安勍：虽然是page visibility，但也是通过自己添加进去。
与会者：我们是标准，这和现有一点冲突，因为现有通过callback既有的方式。
安勍：现有还有初始化做，开发者不需要做。
之前我和W3C的人沟通，如果callback在这里做，因为实际上有个创建的过程，原来不透明，在怎么创建，自己实现的时候开发者是不可感知的。如果做标准用callback的形式，之前我的版本也涉及到callback的函数怎么初始化。所以，怎么初始化、怎么触发的定义，标准层面怎么欧需要做。
标准更多是要落地，不知道是否存在这样的情况，如果通过addEventListener()，可以先做，不需要到开发者做，就到执行层面。
与会者：就是这和现有差异，同构想转也存在变动。
安勍：我看W3C反馈组提出的反馈，如果用这个callback的话，相对会比较复杂，所以之前他们做事件管理的时候，大部分还是采用add listener这样的方式。
王子韬：我重新review了一下，添加DOM的形式，人工的添加操作的情况。我理解安勍这样设计，一定程度上是想从小程序标准化的角度上，更兼容、更接近W3C已有的框架，提供一套标准化的解决方案。
所以，后面无论是从文稿的角度还是参考文献实现的角度，都需要进一步讨论更折中的方式。
尽可能兼容现在的方式，同时考虑到未来，考虑到一种开放的方式，兼容的开发框架。
安勍：我觉得从原来的角度，从W3C，像Google、微软的角度，原来立项时候他们想看到的就是有没有一种方式，让小程序可以和浏览器形成一些映射或者是互操作，或者互通。他们是希望看到这样一点的。
我感觉整个路按照这个目标的话，W3C给我们的反馈，整个方向可能的话，follow W3C通用的做法会稍微好一些。
王子韬：同样的方式，我们是希望更依赖于open your eyes已经讨论的标准或者规范，重新生成一套解决方案。
但是，我认为这个周期相对比较长，所以我们可以考虑在达到最轴目标之前，先逐步有一套大家能用起来的规范，然后再向进一步开放、进一步标准迁移。
这是我的思路。
安勍：好的。我就继续往下。另外两个反馈比较小，正在处理。
就不打开了，比较简单。里面定义了一些feld，他给了一些详细的建议，它建议可以再增加一些关于参数的详细表述，我正在做。这个应该好解决。
https://github.com/w3c/miniapp-lifecycle/issues/32
最后一个是关于无障碍的，基本上已经和提出意见的人讨论得差不多了。只要在无障碍章节加入小程序的章节，是由用户操作触发的，比如小程序到后台操作，和用户无关，在无障碍设计的时候需要考虑这些的一些情况，基本上要写这样一段话在那里，我已经写了一个，已经发了一个pull request。
这是和他们沟通之后写的，小程序有时候对用户的操作会有反应，举了一些例子，比如小程序的global State，标注小程序是前台运行还是后台运行，这些都是有触发的。
这些都比较简单。其他更新不多。
https://github.com/w3c/miniapp-lifecycle/issues/22
昨天终于找到了这个issue的提出方，谁可以介绍一下。
与会者：实际上，当我第一次看Lifecycle的规范还比较早，就是去年。
我们有一个疑惑，Lifecycle大的事件定义都比较清晰，包括app级、页面级的。实际上从小程序实现团队的角度来讲，我就有很多困惑。
就像这张图里提到的，我们是有层次的。它要交互，在这里我们没有看到通知事件在哪里。如果没有通知事件，小程序基本的spack都很难完成。
如果归属为一个层面，这里面会带来一些冲突。
第二个例子，比如页面产生的事件，在view或者是Web View实现，中间处理的JS也是有事情发生的。
这个东西是不是要在Lifecycle里定义，或者是不是有另一本event，或者是什么？那个东西是一直没有看见的。所以，这里可能出现一个问题，在宏观上没有问题，如果映射到实现层面，即使不考虑以以前的方式兼容，但我们必须要回答这两层的交互在不在Lifecycle的管理范围内。
我想补充一点，从顶层实现团队来看，它的是在的。如果没有事件交互模型的event model，可能很多事情没有办法做。
包括API的调用，本质上也会转换为事件，就是表面上看到的API，也是一个事件调用的活动。它还有一些异步的事件，所以在这一块我是比较关心的。
安勍：我先说一下W3C里很多标准的特点。
以浏览器为例，浏览器做的很多标准，我自己个人总结过来哪些适合在W3C做标准，肯定需要浏览器的winder或者是进浏览器的winder（音）做实现，同时标准API会给开发者使用的情况。同时要和Web相关，是在适合在W3C。
所以，这个东西很重要的是对开发者是否可感知，或者开发者可用。
回到这个问题，这也是我的一个疑问。关于红色框出来的部分，也就是MiniApp Framework，是不是仅存在MiniApp winder（音）？
与会者：是的。我们就是Winder，有时候开发者不用关心，但这次标准是站在运行时还是开发时。这两天一直在讨论这个问题，如果是站在运行时的角度，Winder和Winder是否实现。
这些JS会不断触发事件，如果另一个Vendor不知道，会发生很多问题。除非出现另一种情况，A Vendor编译的包，只能A可以处理，不存在交叉的情况。如果这样的话，Vendor内部的实现可以完全屏蔽。但目前为止，我们看到的实际问题是Vendor A编译出来的，发出来的底层消息格式、事件都是不一样。虽然讲起来都很像，但它确实都是不一样的，所以有这样的问题。
安勍：我自己的一个标准就是Vendor之间不可见。这肯定有标准的需求，但具体到W3C，可能相对比较困难。因为这不涉及和开发者太多的交互，我们的一个思路，不妨基于W3C做的CG组做一些事情。
因为CG组可以发一些CG的report，这个report可以包含很多东西，如果几个Vendor确实觉得这些事情可以做，可以在CG里快速讨论一个API出来，直接去用好。
最终它不会有W3C正式的背书，我觉得这还好。
之前这么多浏览器厂商做的标准，让W3C背书，归根到底还是让产业去用。但具体到这个event，只要几个Vendor同意就可以了，之前我们就已经达成一致了，最终是不是要W3C正式的戳就无所谓了，whatever了。
所以，如果要在一个平台，可以在W3C的CG组社区讨论这个事情，我个人的建议是这样。
王子韬：安勍刚才讲的那一点，上午也讨论过，也有老师提过这个问题。就是关于开发态、运行态、运营态的问题，从边界角度来说，W3C更擅长或者更面向开发态的解决方案。一些运行态的事情，不管在哪里讨论，以CG的形式，如果在一定程度上有一定的指导，大家能够基于这个做一套东西出来的话，能够实现这样的互通和互认的话，实际上也是一个比较好的idea。
然后，进一步的说得到官方背书的部分，因为标准开发周期是比较冗长的时间，大家可以看到去年成立的工作组，这几个工作组发布的情况。实际上这些工作组草案之前，在CG讨论也很长时间了。
所以，一定程度上标准孵化有一个初步共识、初步部署到最终标准认可的阶段，大家也可以从实用的角度或者更现实的角度走一套相对来说比较快速的流程，大家先进行一些部署、实践活动，然后返回来，把标准或者是技术备忘录做得更加完善、成熟，生成一个有官方背书，有W3C橡皮图章成熟严谨的标准，这个方式也可以尝试，包括后续的标准建设上，我也建议这样的方式来做，更加高效，也符合W3C严谨的讨论流程。
与会者：刚才听了讨论，我们是不是可以先统一运行态开源的方案有多少个。因为这是开源实现，我也同意，我们肯定是面向开发者，定义一些，可以在一些开源实现里做一些落地的report推荐。因为都是开源实现，甚至还可以有不同的实现方法。
可能这样效率会更好一些。
王子韬：我也一直在考虑标准效率的问题，因为标准周期和开源周期，怎么互相把它们的优势互补起来。一要效率，二要严谨，它们确实可以有一种方式可以交互起来。
与会者：另外，我看MiniApp Runtime，我不知道自己理解对不对，实际上小程序还是有点不一样的，它是想应用的逻辑放一个core里，它有点像extension。
将来小程序的模型，小程序的模型就应该放在set called里。
如果开发者只需要关心called的部分，有没有可能在上面有一个清楚的划分之后，就可以比较明确，别人也比较明确标准落地在什么位置，只是对开发者关心。但有些还是关心Runtime的问题。
另外，我听说有一些要开源，要基于几个开源的project配合标准、配合CG的工作，这个有没有一些讨论？
我觉得这些落地都非常重要。如果从W3C的角度，或者不了解中国小程序，从外面的角度来看，外部会关心架构、影响等等，他们很希望知道这些，并不只是简单的定义一个API，他们有一大堆问题，比如在什么地方实现。
可能有点发散，不好意思。
王子韬：我能理解这个问题。比如有一个很清楚的社区，这些社区里对小程序的架构是否都是统一的，比如这个社区接受的程度。虽然这个W3C的标准不规定怎么实现，但实现的人去支持这个标准也很重要，比如有两类开源社区愿意支持它，或者有些厂商。
王子韬：去年W3C小程序工作组和绿盟有一些讨论，当时就是点对点的。后面的开源组织，有没有可能做一些引进，比如像安勍这边的支付宝、百度，加入新的社区，或者就在小程序工作组下面先做一个预部署的开源项目，我们确实在讨论。后面看一下，如果大家意愿强烈的话，可以用这样的方式run起来，这样的方式更高效。
安勍：可以。就按照这个思路。
好的。我们线下再讨论。我们继续往下进行。
Martin：大家好，现在对我来说是早上。
大家可以看到我的屏幕吗？现在我要现在介绍一下Manifest的流程。
其实，这和之前会议提到的问题一样，大家可以在页面上看一下。
我想和大家讨论一些重点。开始我们列了这样的项目，当然并不是其他就目前重要，只是有一些问题可以简单的解决。首先是“整合”，以目前的方式呈现，比如“req_permissions”的整合，我们进行了很多讨论，这是可以进行评估整合的部分。
我们也可以进行一些适用，这都是相同的逻辑。
这里app_id也是相同的。我们考虑和app_id进行整合，我们也正在跟进。
之前讨论的问题是一样的，这是我们可以达到的问题。
我们正在跟进这个事例。我们也希望在这部分得到大家一些反馈。
1月份我们发了一个对CSP增加新成员的问题，这也是可以纳入的一部分。
比如建立可信任的环境，纳入进来，MiniApp里有权限，比如外部的Java、HTML、图像等等。MiniApp的版本，1月份有这样一些讨论。
不知道大家对这个是否有兴趣。这不仅对今天的Manifest有关系，这是外部潜在的源头。
对MiniApp的这部分也非常有关，它和安全、隐私具有高度相关性。
[多媒体演示] 这里举了一个例子，就不一一赘述了。
目前CSP的如何得到了妥善的解决？
大家对这部分是否有一些疑问呢？
好的。如果大家有问题的话，后续我们可以继续讨论。
我们如何处理隐私问题、安全问题，也必须要讨论一种可能性进行block，尤其是提前设置JavaScript的逻辑评估，这些都是相关问题，并不是要现在讨论，后续大家有想法可以和我们进行积极的沟通。谢谢大家！
安勍：我有一个问题，其实也不算问题，而是一个点评。
目前我们小组有很多讨论，是关于安全的商业模型，我们如何将它应用到native的环境，包括MiniApp，这是需要我们讨论的点，也是需要思考的点。
其中，我们收集了不同浏览器的小伙伴一些反馈，这些都是必须要考虑的。
另外，我们也需要在白皮书或者标准里说一下运营的具体细节。比如Web安全模型等等，都需要纳入小程序相关的文件里，我们需要高度注意这些问题。
Martin：非常感谢，这些意见对我们非常重要，我们会继续跟进大家的意见，这是我们要明白并且要达成一致意见的。
我们都知道小程序与Web有所区别，我们有进行不同的分流渠道，这都是需要我们解决的问题，也需要大家和我们一起讨论，达成一致的想法，从而解决这个问题。
这一点是非常重要的！就像安全和隐私一样，都非常重要。非常感谢您！
王子韬：我们谈到了隐私和安全，我们刚刚发布了2.0版本的白皮书，不知道是否需要重新开始2.0或者其他版本？
我们要和大家沟通一下，看看反馈结果，再看是否需要重新开始这项工作。
安勍：对我们来说，两个方法都可以。只要我们有足够的材料描述。
Martin：好的，我们会继续保持。
安勍：好的。我们继续进行。
Martin：在这方面，这部分的呈现有三点需要和大家确认。
接下来是如何验证app_id以及运行时间，之后才可以运营MiniApp。如何根据app_id确定的工作，我有一些基础的经验，大家的反馈对我们来说都非常好，都很有帮助。对MiniApp版本，以及对app的识别等等，确认MiniApp环境也非常重要。
有什么不同的模块和板块，我们进行了MiniApp的陈述，比如安全性的环境，我们必须要确认主要模块有哪些东西，它是可编辑的还是参照的，我们如何确认app之后，再进行load。
对于小程序的呈现，首先要识别它的IP，尤其是识别阶段，app内部的整合性也需要人。
大家对我刚才提到的问题有一些反馈吗？大家有没有一些想法吗？
安勍：现在测试的数据更新，对我们来说可以很好的看到整体效果。如果有一些具体效果或者具体测试会更好一些。
Martin：好的。之后我会给大家提供一些解决方案，一些solution，如果大家有具体的想法可以及时和我们联系。非常感谢！
以上是对Manifest的陈述，这是我们想和大家讨论的问题，如果大家对Manifest有一些问题的话，可以提问。我的介绍就到这里结束了。
安勍：我们好像没有一些额外的点评。
Martin：好的。这是我们对Packaging，我们已经有数据性的审查，horizontal review。
开放性的问题主要是连接与孵化问题，也就是split content and Packaging。这是我们去年讨论过的问题，我们决定把它和Packaging分开，这和我们的组件有关。定义小程序，如何进行pack以及容器如何进行迭代，和孵化器等等，需要定义好在不同资源Packaging之间的关系进行识别，这和之前的问题也有相关性，包括得到外部资源等诸有此类的问题，其中也有隐私和安全的问题。
这里的图并不是特别清楚，所以还需要大家进一步讨论。如何定义在小程序中的基础组件。同时也是进行wide review，这些都是我想给大家反馈的。
安勍：好像没有什么问题。我们仍然在等待着横向小组的反馈。
我们将进行下一个问题，Martin。
Martin：好的。我们想向大家展示一些改变。
安勍：这个和下一个环节将进行的展示。
Martin：好的。
安勍：下面有请百度的同学。
周丹：URI提出比较久了，在去年比较早的时间就review了URI的语法提案。在之前的提案里，我们是希望标准化，但这可能有些违背Web尽量减少新增的原则，我们希望S性尽量使用http的协议进行访问和定位。
基于这个原则URI，变成了向deep link靠拢的现状，这更符合各个厂商实现的现状，所以在新的标准里参照了两套方式，一个是deep link协议，一个是自定义协议。
关于为什么需要自定义协议，review还没有开始，如果review之后估计也会存在一些争议，就像之前说的到，我们要做标准化，也要考虑落地。
现在大部分厂商支持自定义协议的URI情况更多一些，从兼容性、可实施性来讲，在提案里约定的这种方式可能是更合适的。当然，我们也希望Vendor们可以尽可能将自己的访问协议迁移到http协议。这是我想讲的点。
除了协议头以外，在这里主要约定的是语法，我们希望开发者给用户角度来看，MiniApp的URI是一致的，尽可能一致的。可能由于现在各家Vendor的packge不通，所以我们使用完全一致的URI还达不到，所以里面提到的platform就是给各家厂商标识厂商的部分。
但是，会有URI 还是统一的MiniApp字符，这些细节需要大家下来再看。
我们主要是介绍里面几个主要的考量。
安勍：大家有没有一些问题想讨论
下一步准备时候再发起？
周丹：我下来再沟通一下，现在还有一些问题需要确认，我觉得可能需要下一步。
安勍：好的。
关于URI没有什么补充，但关于标准化开放态、运行态、运营态的事情会在CG会议的时候再发表一下观点。
安勍：如果关于这个话题没有更多讨论，进行下一个。
小米的同事在线上吗？
赵小平：因为之前我们的工作在CG部分会再讨论。
安勍：好的。我们几个小组的进展基本上到这里了，比日程慢了几分钟，我们先茶歇10分钟左右。稍候再进行下一个环节。
返回会议总结页面获取其他话题的会议纪要。