Meeting minutes
Welcome
Wendy: Welcome everyone, good to see you on the second day of the miniapp meetup
… let's give people more time to set zoom and interpreter tool
… you could use this URI in the shared screen to find interpreter instruction
… our IRC channel will be #miniapp
Xueyuan: [introduction on how to use Akkadu]
… please lower the akkaddu volume when you speak on zoom
Wendy: today we will have full schedule, miniapp URI, miniapp & IoT, and a break. Follow up will be MiniApp & Web Platform, MiniApp Standardization, and conclusion Wrapping up & Next step, hope you enjoy listening and participating in the discussion today
MiniApp URI Scheme
Wendy: I'll turn it over to zhoudan for miniapp URI, thank you for the terrified introduction you gave us in advance
zhoudan: Zhou Dan, I'm going to speak in Chinese
… brief introduction about miniApp URI, the proposal defines a Uniform Resource Identifier to get access to a MiniApp
… the scheme miniapp: is to indicate this is a URI of a MiniApp, id and version is to identify a MiniApp package. Host tells where to obtain the package, path is for the index page. It can be an anchor, or the location in JS. Our expectation is, if a browser supports miniapp, then it can identify a MiniApp URI and launch the MiniApp.
<wseltzer> Slides on MiniApp URI Scheme
zhoudan: slide 10 and 18 explains the parsing process of a MiniApp URI. For a WebApp, browser knows how to parse the anchor. If you want to visit a Webpage in the MiniApp, it will ask the webview components to load the page. To visit a miniapp inside a miniapp, it will switch by certain miniapp apis. Slides p10 explains why we need a new MiniApp URI scheme.
… miniapp has an independent runtime, it contains logic, engine and render view. It takes some time to finish loading the runtime, as MiniApp itself is a package, which also require loading time
… If we are to load the runtime after finish loading the pacakge, then the first screen will be blank for a long time. That's why we need MiniApp Scheme to predict it's going to be a MiniApp
<slightlyoff> thank you, xfq
zhoudan: there is no way to identify the resource type in the current HTTP protocal. Our goal is not to create a new URI scheme, but to keep this resource type predict and improve the performance. From this URI proposal, when a user see a MiniApp URI, he/she knows it's going to be a MiniApp and where is this MiniApp. This needs support from the browsers, if the package is problematic, the UA should give warning and forbid this visit. Questions?
Yves: W3C staff, in English
… there are two issues, a URI is just a name. you are going to face the dereferecing, that involves multiple steps, in the evil case there is DNS, and then estabilish TCP connection, estabilish HTTPS, estabilish the next circle connection, then requesting what you want
… in past, we thought it's not the only way to dereference the URL. In the categary, there is a way to describe in the OS for certain URL the content directly from the system, without going through DNS and whatever. Later on, it was replicated with Service Workers, who are acting like a local cache of concent of webapps, another way of doing that is through web packaging, which is like multiple caches which can be transfer to different places.
… In that case, the usual way to do extension in the Web, for a new application, like video, it's not using URI scheme, but to use media type. In that case, when you are requesting, like a package, that can be a MiniApp, without upfront for the reponse, the content type can say that, oh, it's a miniapp! Dont wait for the entire download to figure out it's a miniapp. Of course it's different from knowing upfront from the URL, but as I said, URL is just a name, it's not supposed to add sematic to that name
<slightlyoff> another way of restating Yves' point is that we can provide cacheable packages for URLs and indicate miniapp identity via mimetype
Yves: that's why from the TAG's view it's a bit werid to create a new URI Scheme for MiniApp. it was tested in the Widget, but as we said, it created issues also risk to the security models
… we still have lots of issues should be addressed. there are multiple ways of using the HTTP URI scheme that's not to be an entire load, like local caches, catelogs, packages that can be storaged in the system, and do resolusion and diverse to a package for certain subtree, there are many ways... that's why we want to know the exactly use cases. how do that work if the miniapp is not installed, if it's not installed but it's a HTTPS URL, just a fetch and realising content type will be miniapp will be enough, after that, check the access, the rights, and be careful not to transfer those information that has been uploaded... there are many issues we might want to discussed on that
Vitaliy_Zasadnyy_Facebook: do you ever consider to modify the current model that the current native applications are using? Like we have native app associated with web domain, and we use a position file locate that owns the domain
<slightlyoff> for instance, we can host all other sorts of media types (video, audio, html, PDF, etc.) within packages and Service Worker caches
<xfq> s/@@: have you/Vitaliy_Zasadnyy_Facebook: have you/
PLH: it looks like MiniApp doesn't necessarily have a new URI Scheme, they have a set of use cases that they actually would like to fulfill, URI Scheme is potentially one of the way to solve it but there are other ways to address those. Today you don't need to download an application to read the description of it because we have store where the information are available. It looks like we need a way to associate meta data information that the user can choose to install the information or not before downloading the package. we also heard that on IRC Alex mentioned one of the reasons why they are using CBOR instead of the Zip was because you have to download the entire Zip before you can start accessing the zip file itself because the metadata information about how to read the zip file are not in the beginning of the zip file unlike CBOR, so I don't if adding information upfront will help the problem, my guess is not, but it might help issue as well
<vzasadnyy_fb> I'll share it in a second
<Yves> doing a HEAD on a URL for a mini app could give information (via Linkk: header) about description, on top of the media type and payload length
Wendy: Vitaliy, if there is any file you can share with us that will be very helpful, thank you very much!
zhoudan: putting the information in the beginning seems to be a helpful idea, to the MiniApp package, it can help to predict a MiniApp
… but our goal is to pre-load the runtime of a miniapp. Would like to further the discussion on different use cases, which group will be the best place? the Web Performance WG? we still have a lot of questions on these suggestions
<Yves> I would suggest the TAG more than webperf for this, but webperf can have hints
<Ralph> ["have a conversation with", not only "present to..."]
PLH: we can certainly bring a presentation to the WebPerf WG. I'm part of the WebPerf WG myself, I feel like it'd be very important to get the use cases right, and I know that the miniapp cg have been working hard on it. I'm certainly happy to help create connection with the WebPerf WG
Wendy: Yves also mentioned the TAG can be a place to talk about the format and experience about the performance
<slightlyoff> zhoudan: when you say that you want to understand it is a mini-app before it loads, does that involve inspecting the zip file? Or do you need to know even earlier?
yongjing: most tricky part is for the cases of local loading of the miniapp, in that case which there is already a miniapp package in the local device, we need a way to let the OS to inform the hosting platform of MiniApp to get early preparation.
<Yves> yes, the system should have a way to register that resolution of URL might end up in a miniapp (that was my XML catalog example)
yongjing: Looking at slides #18, there is a use case describing how you can decide this is a request or a link pointing to a MiniApp or just a HTTP, if we use the miniapp prefix, by having this kind of prefix, the OS knows it needs to loadup the environment and get early preparation. but if it's only a HTTPS request, it will need some more steps to predict it's leading to a MiniApp or some other apps.
Wendy: Thank you! We've some discussion today and we should definitely follow up knowing the use cases and important questions
<Zakim> MikeSmith, you wanted to mention other reasons for not coining new URI schemes
<Yves> as the mini-app is trusted (through a store) it is legit to have resolution in the space limited to the origin of the mini app done thtough the said mini-app
<xfq> TAG discussion
<slightlyoff> zhoudan, Yongjing: have you investigated Android's intent filters?
Mike: I haven't read the TAG's discussion about URI scheme, in a very high-level, one things I want to say is you need to understand how much of a messy battle you will be facing to invent a new URI scheme. It's not something you want to do it unless you have a super super compiling case for it. Going back to describe what you need and what you want to do is a good starting point of another discussion, especially the problem description.
<wseltzer> [I note that zhoudan's slides show good flowcharts]
Mike: you are not going to able to use JS to manipulate or just make a request from MiniApp URL using a fetch or interact with script from those URIs; and Content security policy which is heavily use on HTTPS or HTTPS URLs may not be available. Most of the work around crose orgin access to resources, the security model of the Web, and security features are aligned to URI to allow developers to access with scripts
<Ralph> [Alex, what are the analogs to Android's intent filters in other environments?]
Wendy: Zhou Dan's slides have some very beautiful flowcharts about the resolusion path ways that MiniApp used or want to use, those are very good input to the discussion. How do we serve that with the good design principles we know about the Web platform?
<vzasadnyy_fb> @xiaoqian
<vzasadnyy_fb> Android and iOS has implemented very similar approach to associate native applications with https URLs. Flow: 1. User want to access https://example.com/product/123 2. Host platform (host super app) verifies if there is Mini App associated with the current domain by checking https://example.com/.well-known/app-assosiation 3. If app-assosiation file is present, get metadata where Mini App (native app) can be downloaded 4. Launch[CUT]
<vzasadnyy_fb> Docs:
<xfq> Intents and Intent Filters
<vzasadnyy_fb> Android: https://developers.google.com/digital-asset-links/v1/getting-started iOS: https://developer.apple.com/documentation/safariservices/supporting_associated_domains
Alex: Hello, Zhou Dan. Thank you for the slides, they are incredibly informative. I'm curious about whether the group have looked at a way Android has provided which is called intent filter? or just to say allow specific applications to use pieces of URL space, say HTTP or HTTPS calling // then an origin plus other explicit information to always direct those navigation to individual applications when they hear. It may provide a solution to the question of browsing to specific applications.
… I'm curious to know if the URL scheme here is being constructed in order to work along the fact that other OS such as iOS don't have the compatibility? If that's the concern or the source of the concern, I think that makes much point
<hober> on Apple platforms, you could use Universal Links: https://developer.apple.com/documentation/uikit/inter-process_communication/allowing_apps_and_websites_to_link_to_your_content
yongjing: what Alex proposed was very close to the question and the solution, actually we discussed a bit about the technologies, f.ex, the deep link and applink, that's something we are considering in this problem phase, but one of the issue is, if we are to do similiar things, the host platform can have a registry in the OS, it can work but not perfec, because each application or each hosting platform can only registered their own URI domain space, but it may not be able to identify other passport things
… also when a MiniApp is delveoped by companyA want to register in PlatformB, it may not be recognised by PlatformB because B doesn't know about the domain of A, so we are wondering if we are going to this direction then if we should have some common domains maintained by a third party or by a authority to be reserved for MiniApp so that every MiniApp vendors, A and B, can understand each other's URI, and those reserved domains were for MiniApps not normal HTTP requests. This can be a posibility requirements
<slightlyoff> thank you, Yongjing!
yongjing: we were not insisting inventing a new URI scheme, just want to explore which is the best way to reuse the existing HTTP scheme to fulfill these
<Yves> you can also set metadata in the HTML to indicate what is intended in a link, that might help early optimisation
Wendy: Thank you. This fits into our goal to make MiniApp introperable with the WebPlatform, cross platform, cross device...
Zhoudan: as Yongjing and I mentioned, our purpose is not to create a new URI scheme, we want to meet the requirement to preload the runtime of a MiniApp by predicting it's going to be a MiniApp. I'd really like to have more discussion with you all, to use HTML content type or Zip. We really like to work with you, thank you for all the help and suggestions. In slides #20 we listed another possibility to have a centralised server, to use Origin to identify a MiniApp, this would require a unified origin for MiniApp, we are still thinking about how realistic is this proposal
MiniApp & IoT
shenping: Shenping from Alibaba
… with the connection with the Cloud, and the data saving in the Cloud, the technologies is difference from before. Faster version upgrade, diversified abilities, requirement for Big Data, etc. But we are still using the traditional way to develop miniapp for IoT, see #2 in my slides
… meanwhile, the number of MiniApps is growing very fast in the mobile platfrom. MiniApp supports hot upgrade, the developement cost is low, we take it as a future solution for the problem I mention earlier. We proposed to apply MiniApp in the IoT field, not only as a type of apps, but also as a new type of runtime or app platform.
… now most MiniApps are run in superapps, f.ex., WeChat or AliPay, the JS APIs or components are mostly designed for the mobilephone device. IoT devices are different, we need to control the sensors, we need more network protocals, that's why we want to extend the current MiniApp technologies. Please check the detaisl in slide #5 and #6 explains our vision for the future IoT MiniApps, it's not going to replace or create a new type of MiniApp, but to extend the current MiniApp technologies. Look forward to future discussion.
<kaz> [Kaz Ashimura - W3C Team Contact for the WoT WG]
Kaz: thanks for the presentation, this is a good idea. MiniApp is a good technology to help IoT. As you may know, W3C has a dedicated WG of WoT, which is using Web technology for IoT.
… We published some standards for WoT in April this year. We are working one 2nd phrase. So it'd be great if you can bring the idea and use cases to the group, and consider cooperation with us. Thank you!
Wendy: Thank you Kaz, who is part of the W3C Keio team, serving as the team contact of the WoT WG. thanks for offering to help connect the discussion.
fuqiao: I have some general questions for the scope and plan for this idea, will these standards for smartphones or IoT devices? Or both? Is it high-level abstraction? Or low level APIs talk to hardware directly? Or both? Apart for the WoT WG, I'm work on for Devices and Sensors WG, and there are some related specs and discussion there, feedback is welcome
shenping: I mentioned in my slides, we want to define both high-level and low-level APIs, covering sensor, bluetooth, control on devices. We wishes MiniApp could allow developers to access these abilities with JS APIs. Thanks.
fuqiao: there are also work on APIs for sensors and bluetooth in the W3C Device and Sensor WG. If the scope of the WG has overlaps, we would like to have joint group discussion about the concepts and use cases.
shenqing: there are many use cases or technical details that we want to discuss with you, we could take them offline
<slightlyoff> would second kaz's point about the Devices and Sensors group. We're pushing APIs forward for many hardware interfaces there, including Serial, USB, HID, and USB in addition to Bluetooth and NFC
Wendy: a big goal of this meeting is to help people find the right contact to continue the conversation
Kaz: I also suggest you join the WoT WG meetings at some point. We should have a joint session during the upcoming TPAC 2020 in October, probably by WoT, MiniAppos and DAS, three groups at once. Thank you.
Wendy: The presentation for this workshop can also be shared with the WoT WG for preparation for more discussion on TPAC 2020
… any other question?
<slightlyoff> even if we are not able to achieve alignment in other areas, we should be able to standardise APIs for device access
Wendy: another value we can offer from the W3C WGs is to think about the security model and the privacy model. For example, the Device and Sensor WG have been discussing for a long time how to explain to the users about the consequence of such APIs, so the users wont be surprised about the expection of these APIs, for example make them easily fingerprintable or indentifiable, and without user expecting that. And I hope there is opportunity for conversation the privacy group about these subjects as well, how can we build a rich and featureful platform without giving access to these capacities and make sure our users are to use them safely. There are good opportunities among these topics.
anqing: In response to the comments on IRC, re MiniApp IoT APIs, there is definately opportunity to work together. But the major use case for IoT MiniApps is for the IoT devices, while the Devices and Sensors WG are focusing on the smarthome use cases, if we are create a create a joint discussion, we should also consider the IoT devices other than the Smarthome. We also hope in the future we will have more joint discussion with the W3C WGs/CGs. Besides the bluetooth API in W3C, we also see the value of bluetooth mesh in IoT. Hope we can look at these use cases in the future.
<slightlyoff> +1 to collaborating on mesh APIs
<kaz> (fyi, various use cases are being collected for wot: https://github.com/w3c/wot-usecases/tree/master/USE-CASES)
<slightlyoff> Qing_An: my team would love to understand your needs better; we have been expanding into BTLE scanning and predicted that we will need to address mesh, but haven't expanded Web Bluetooth to do it yet. Would love to collaborate on that.
shenping: thank you for the feedbacks. Our goal is to allow the IoT developers to take advantage of the new technologies to easily develop IoT applications, with access to the device capacities. We see the potential in MiniApp. Look forward to discussion with the other WGs as well, to talk about requirements and use cases so that we can consider an extension for MiniApp on IoT.
Wendy: we will have 10 minutes break
… will start with PLH's talk
<Qing_An> To slightlyoff: agree with that. We have done many implemention on Mesh. We believe standardized Web API can bring benefits. Look forward to further discussion.
<wseltzer> [break]
MiniApp & Web platform
Wendy: MiniApp & Web platform from Philippe Le Hégaret, W3C Project Management Lead
PLH: I want to talk about the difference between miniapp and web platform
… the Web is global
… the miniapp CG have prepared four specifications, based on their use cases and requirements
… hope the miniapp and web platform could be harmonized
… as we mentioned in the previous sessions
… at present, there are still some gaps in Package, lifecycle and URI scheme
… URI scheme is for discoverability
… Alex mentioned Intent Filters
… Tess mentioned Universal Links on the Apple side
… we need to look at existing solutions
… we need to learning some resolution way on mobile side
… IoT is new to the conversation, but again we have existing groups in the Web platform
… we need to work together, like on mesh APIs
… one topic that was briefly mentioned yesterday is style
… we haven't discussed that in detail
… a topic we haven't discussed yesterday and today is security and permissions model
… we're struggling on the Web to get it right
… it's extremely difficult
… the user just opens a web page, no need to install anything
… but in native apps and miniapps, the user needs to do a little bit more to access and use the application
… and this does impact the approach of security and privacy model
… we should also develop a timeline for those goals
… it was mentioned yesterday
… the overall goal is to let the miniapp leverage the web platform
… but note that miniapps are not just restricted the web platform, but also allows native solutions
… if you do agree with me, I'd like to hear what you think, especially from the miniapp editors
… optimistic or pessimistic?
… also want to hear what the TAG think
… I'll stop here.
Wendy: thank you Philippe!
… do participants want to respond to Philippe's questions?
zuming: speak in Chinese, coming from Baidu
… glad to attend this meeting, we'll participate more in this area
… there is an essential question, it will affect a lot of our decisions
… the runtime environment of current browsers is quite different from miniapps
… in Baidu Smart Programs we use V8, but runtime environment is quite different from traditional browsers, and more like native apps
… we use Yoga and Skia for rendering miniapps
… some browsers in China can run miniapps, but they have two different architectures for running web apps and miniapps
… what do we expect for the future runtime environment?
… we should answer this question sooner than later
… the first approach is to modify existing browser runtime and make it run miniapps
… the second approach is to use different technical architectures for running web apps and miniapps
… both approaches enables web browsers to run miniapps
… the first approach is quite different from our current approach and may not meet some of our needs, although I can't list all the needs here
… but the second approach might be different from the goal of W3C
… this is my question, glad to hear what you think
Wendy: thank you! Philippe, would you like to respond? Or shall we move to the speaker queue?
PLH: I can't speak too much on differences on two models
… because I haven't dived into them myself
… appreciate on you mentioned this issue, we should look into this
… in the end it might be possible that we have two different models for the web and miniapps
… I don't have an answer for you today
<Ralph> [I would hope that we can learn how to extend the runtime framework such that it supports MiniApp and WebApp in a fully integrated fashion]
Wendy: Ralph is noting on IRC that we should learn how to extend the runtime framework such that it supports MiniApp and WebApp in a fully integrated fashion
… thank you Ralph
<slightlyoff> speaking only for Chrome, I'd imagine that expanding to process a different type of content that can't easily run on Windows, Mac, and Linux would be difficult. The extent that we can align miniapps around HTML/PWA tech to enable the broadest possible reach seems valuable to developers
yongjing: the primary thought on miniapp when we develop miniapp is to use web technologies as much as possible
… we're open to ideas and it will be ideal if browsers can also run miniapps
… but we should also remember if we want to achieve that goal we need more contribution from the browser side
… in the meantime we should not forget the original driving force for the miniapp work we're working on right now
… and we also want to make the miniapp works like a native app with usage of web technologies
… we should try our best to achieve both goals
Wendy: any other comments from participants?
PLH: notice the comments by Alex on IRC
… the web is more than just the mobile platforms
… we should make sure the web works on OSs other than mobile OSs as well
Wendy: yes
… device independence is important for developers
Wendy: next topic will on MiniApp Standardization by Angel, who chairs the miniapp CG
MiniApp Standardization
Angel: we have been clarifying and exploring our way forward
... vendors in the MiniApp CG have rough agreement to move forward
... but still need to discuss here if that fits in the big picture
... we need to first solve practical issues, e.g., for MiniApp developers
... they want to build interoperable MiniApp across different MiniApp platforms
... they need a specification on this topic
... MiniApp vendors need a place in W3C to build specs
... with proper process and patent policy to meet the industry requirement
... based on these considerations, the MiniAp CG prefers to have Working Group
... focusing on MiniApp standard spec
... also need to re-conseive the ongoing work, esp the current four proposals reviewed by TAG
... so, here are some suggestions and comments welcome
... 1st, the MiniApp CG will continue to improve the draft charter for the WG
... esp to redefine the group scope and deliverables
... probably need to drop some overlapped content that not incubated maturely
... 2nd, once we launch the Working Group, we need join Task Forces with related WG when feasible and necessary
... figure out which are the related groups to cooperate with
... these above are brief summary from me
<xfq> [DRAFT] MiniApps Working Group Charter
<xfq> Current charter issues
Wendy: I share my screen to capture your suggestions
... that the MiniApp CG refines charter for MiniApp WG
... plan joint TFs with other WGs
... I heard suggestions including the following groups:
... Web Applications, WoT, Devices and Sensors, TAG, PING, WebApp Security to think about further model for MiniApps
... Angel, do you think it's a good starting point for next steps?
Angel: Yes
... I'm not sure about global community's reactions when we start the AC review for MiniApp WG charter
... also, we do have some issues to clarify first, e.g., Lifecycle standards in different places
... maybe one document could help the whole picture of Lifecycle standard
... for WebApps, MiniApp, Web Pages
Wendy: hear requirement of single communication point for MiniApp developers
... it'll be helpful to have one guidance document to collect the points in one place
... wrt the global community reactions, that's why we have preview and input here
... before shipping a charter that meets their interests to build a global platform
Kaz: joint TFs might be complicated as a starting point
... instead, I'd suggest joint meetings with other groups first
... to think about possible joint TFs next
Angel: sounds reasonable
Wendy: yes. we could start with joint meetings with other groups
PLH: we need to make sure to have right people in the right table
... IoT one is new on this table
... I prefer the MiniApp CG to refine the Manifest spec and continue to have WebApps WG engaged in the debate
... Yves mentioned the TAG might help on the discovery ability for URI Scheme issue on a overall solution
... How to move forward the Lifecycle, I don't have an answer yet
... the Web Performance WG needs to be on the list
... we did have Page Lifeclye discussion in the past
... need answer questions on runtime, maybe in Service Workers WG
<Yves> SW can definitely help on the cache side, but implication on the runtime and underlying OS are not in their charter
Angel: about the charter, the CG has discussed and reviewed it
... but the lack of enough global participation in the discussion might cause problems
... if the scope and deliverables are not well designed
... so any suggestions on the scope, esp from global stakeholders here?
Wendy: call for us to look at how to make this a global conversation
... how to refine the group scope
... comments welcome
... e.g., the team will discuss how to make step by step progress
... look back at the Web Fonts WG, chartered first to produce reports to check options
... after that, then pick an option for normative deliverables
... sometimes we know a clear path forward and sometimes we don't
... when we are still at early incubation stage to find out solutions
... in the charter, we say we will explore and come back for review before kick the solutions
... a way to charter a group to include the incubation phase to limit the patent commitment
... then come back to membership when we have definite directions
... that's a possibility
... a comment on IRC that we need to consider Accessibility (WAI) aspect
<xfq> Deliverables section in the Web Fonts Working Group Charter
Kaz: within W3C, I work for the Media and Entertainment Interest Group (MEIG) as well, and I think maybe the group's approach would make sense for MiniApps discussion as well, i.e., as a central hub for discussions on use cases and requirements, then send requirements and proposed APIs to all the related groups
Wendy: sounds an good idea.
... any further opinions from TAG about next steps?
Theresa: TAG encourages joint meetings and TFs
... as many experts in other groups have better experience to share
<tidoust> [I was more understanding Kaz' comment as suggesting to create a MiniApp IG instead of a WG, to collect use cases & requirements, and liaise with other groups responsible for specs of interest, which could be a good idea to start with]
Wendy: happy to hear the willingness to share expertise
... your feedback will be really helpful on this
Jeff: I am from W3C. Thanks Theresa.
... since some other key people on TAG are not available today
... could you let them know the consensus position of this meeting and next steps?
Theresa: sure.
Angel: Wendy, I like your list of groups to cooperate with and next steps
... we also need timetable
... I will push the CG to refine the draft charter in Aug and Sep
... meanwhile, we will reach out to related groups
... if things go well, we can have the refined charter before TPAC
... then start AC review in Oct if possible
<slightlyoff> I want to second hober's comments about joint meetings. I'm encouraged by the areas where the miniapps designs thus far can help push a joint vision of the platform forward. There are gaps in the web's surface and speaking only for my team, we're keen to understand and collaborate on closing them
<xfq> https://www.w3.org/2020/10/TPAC/Overview.html
Wendy: reminder that our TPAC will be virtual meeting
... a week for breakout discussions for plenary day
... it will be a good opportunity to discuss the draft charter
... suggest to use several TPAC sessions to discuss specific items
... make sure the full community to give feedback before AC review
Angel: I hope it will work.
... we also need to refine the current MiniApp specs
... I don't think we should pause those specs development in CG
... we expect them to be more mature once we refine the charter
... Could we invite you to join us in refining the MiniApp WG charter?
Wendy: gladly. Thank you.
PLH: Yes, the CG needs to keep refining the proposals
... so that we can have a better shape before mid Sep to answer questions
... advising the CG to identify tech approaches and an interface between WGs and TAG
Wrap up & Next step
Wendy: Wrap up for the meeting
... I encourage people to queue up if you like to share with our audience
... think more of us can join the MiniApp CG and continue the discussion
<xfq> +1
<xfq> this will make addressing horizontal review issues harder too
Kaz: like Francois and I mentioned on IRC
... an Interest Group instead of Working Group might be another option
Angel: the CG has discussed this
... actually the CG already plays a similar rule as an IG
... like collecting use cases and requirements
... the preference is targeting at WG instead of IG
... we have a lot of gaps to solve and the IG may take us a year or longer
... but the market might not wait
Wendy: I think we share your interest of moving efficiently and meeting the market need
... Alex comments in IRC, sharing interest in joint meetings
... the joint discussion can begin now
... the CG can communicate with related groups listed above immediately
... we, W3C team, encourage the Chairs and Team Contacts in these coordinating groups
... to learn more about MiniApps use cases, gaps, coordination, etc.
... think about extending their specs to fill with the inputs
... we should continue the outreach with these other groups that are developing web platform features
Angel: we should also make sure these MiniApps specs don't get overcooked in CG
... to leave us enough room to improve in WG
... what to for market and what for standardization
Wendy: yes. It's important to mention our timelines with the needs
... noting on the slides
... if we can do gap analysis of existing tech against MiniApp platform needs
... e.g., in your presentations of Manifest and Lifecycle
... then existing groups can see if they can fill by extensions, or the need from MiniApp side
... or there're existing tech that aren't yet considered
... maybe be a way to build joint table for this
... help existing platform features to serve MiniApps better
Angel: Thank you, Wendy.
Wendy: nearing the end of the meeting.
... Thanks everyone who's been engaged to this discussion.
... we made good progress on objectives that we built
... of understanding MiniApp tech, web platform interaction
... gotten good inputs and identified opportunities for dialog
... as well as identifying specific WG, IG, CG
... hope that helps us in continuing connections as this work goes forward
... What's the schedule of the CG meeting?
Angel: we have monthly CG call at 8am EST, usually 2nd Thursday of that month
... next call on 6 or 13 Aug, will check.
Wendy: perhaps we can offer a report of this meeting to the CG
... and use that to sync our conversation
... Thanks again everyone for joining the meeting
... Thanks our scribing, interpreters, Beihang team
... Thanks all the participants helping to liaise with broader community
... we will share the meeting minutes with attendees to review
<wseltzer> Slides shown on-screen with real-time editing (p. 6 and 7)
[adjourned]