W3C

– DRAFT –
MiniApps CG Monthly TeleConf

17 June 2021

Attendees

Present
Changhao_Liang, Dan_Zhou, Kester_Bishop, Martin_Alvarez, QingAn, tomayac, Wenli_Zhang, xfq, xiaoqian, zhoubingqing
Regrets
-
Chair
QingAn
Scribe
xfq, xiaoqian

Meeting minutes

Progress of MiniApp for IoT

QingAn: This issue raised by me several weeks ago, and I prepared a draft with a proposal.

[QingAn shares his screen]

https://github.com/w3c/miniapp/issues/157

https://rawcdn.githack.com/QingAn/miniapp/gh-pages/specs/IoT/index.html

QingAn: in previous meetings people asked the use cases
… so I mentioned the use cases in this draft
… I also mentioned the architecture
… packaging and lifecycle in IoT
… in section 2 I listed a few use cases
… switch panel with a screen and several physical buttons
… use case is to control the HAVC applications and lighting applications
… the switch panel UI can be developed as a miniapp
… another case
… an example of HAVC and lighting application switch panel which has a touch screen
… the second use case is gateway
… local connection functionality and cloud connection functionality can be designed and developed using Web technologies
… the third use case is the very popular smart speaker
… touch screen on the smart speaker
… the fourth use case is checkout pad
… e.g., in a store, café, or supermarket
… usually a checkout pad has a screen and a camera
… by introducing MiniApp for IoT, the checkout pad’s screen UI and camera can be developed using Web technologies
… video conference terminal
… face recognition terminal for access control
… provide employees with quick and convenient access to the workplace
… these are the current use cases
… but we have more than that
… MiniApp for IoT Architecture
… similar to the architecture in the MiniApps standardization white paper
… MiniApp for IoT is running on top of IoT OS
… not necessarily on top of a super app
… have components and APIs very similar to miniapps on mobile
… key features include IoT communication protocols, I/O for peripheral, and hardware functionalities
… in section 4 I analyzed what we should do wrt packaging
… gap analysis for MiniApp Packaging for IoT device with a screen and without a screen
… a simplified packaging directory structure
… for IoT devices without a screen
… for example, the CSS Resources are not required
… section 5, MiniApp Lifecycle for IoT
… extend MiniApp lifecycle to include one new global application lifecycle event for MiniApp for IoT
… and a new lifecycle state
… also for miniapp page lifecycle
… the last section is MiniApp APIs for IoT
… to interact with IoT device native capabilities we should define a set of APIs for MiniApp for IoT

[QingAn goes through the APIs]

QingAn: these APIs are fundamental for IoT devices
… these are the content of the current draft
… any comments?

martin: nice work
… this could be a good opportunity to the maker community
… the open hardware community
… UI options
… they already have a lot of options for connecting things to access sensors
… but they usually don't have proper UI systems
… it could be good opportunity to provide them options to make UI
… regarding the first use case, switch panel
… there are a lot of opportunities if we mix with WoT
… MiniApps could understand automatically their configuration via semantic description
… wrt configuration of the IoT platform
… I'll show you some more use cases
… maybe next week
… for open hardware community and all the WoT applications
… might also affect accessibility
… I've been participating WoT WG and IG
… one of the use cases they discussed was the possibility to offer advanced accessibility features for disabled people
… based on semantic descriptions
… I'll review this document and comment

QingAn: thank you very much for your comments
… I agree that we should talk with other groups
… like the WoT WG and IG
… we should work with existing groups instead of overlapping the existing specifications
… if you can share with me next week we can work together
… one question
… is the the open hardware community within W3C, or is it an external community?

martin: DIY applications on top of IoT
… hardware prototyping using Raspberry Pi etc.
… I'll bring some use cases based on this

QingAn: it would be great if we can find some points to work with them

QingAn: this document is in my personal repo, do we want to move it to the w3c/miniapp repo?

xfq: Because other specs have been separated from this repo, I suggest that we do the same for this document. I can create a GitHub repo.

Update mechanism of MiniApps

https://github.com/w3c/miniapp-lifecycle/issues/8

QingAn: version update mechanism of MiniApps
… I think it's different from the things in lifecycle
… currently if there's a new version in the server, there's a prompt in the screen
… if the user click yes the app will be updated and reopened

[QingAn describes the version update process]

xfq: I agree not to write it in the Lifecycle spec
… but it's related to Lifecycle
… we need to specify when mini app will be cached and updated
… like cold launch or hot launch
… related to the miniapp events

Dan_Zhou: I think this mechanism should be sepc'd in the Manifest/Packaging spec
… Lifecycle is limited to the runtime
… manifest is related to the version (the version_name and version_code members)
… each time when user open a miniapp
… if there is a new package
… it will show some dialog to ask the user if they want to use the new package
… we should discuss the core logic in the packaging spec
… I'll write it down in the issue

QingAn: agree that it's not about the runtime
… manifest and packaging spec would be a better home for it

martin: in the packaging spec, there is room for such use case
… how to config the packaging, the cache, the update of the miniapps
… the place to declare these
… the algorithm to config how to open a miniapp the first time
… the fetch algorithm for the package
… we can include more steps
… not sure if we should include something similar in the lifecycle spec
… I'd be happy to continue the discussion offline

Resolution: start documenting this in the Packaging spec

Action: martin to open an issue for lifecycle #8 in the miniapp-packaging repo

need more information about why PWA isn't enough

<tomayac> I want to note that what PWA can do is _fundamentally_ different on Android compared to iOS.

https://github.com/w3c/miniapp/issues/165

QingAn: the hosting platform for a PWA is a browser

QingAn: but the hosting platform for a miniapp is a native app or the OS

QingAn: can we update the white paper?

tomayac: essentially what PWA can do is very different on Android compared to iOS
… on Android we can do hardware access like WebUSB, Web Bluetooth etc.
… if you say PWA is good enough this is not something that is a true statement
… we can probably say PWA is good enough on Android
… but not on today's iOS

QingAn: it would be useful if you can comment on the GitHub issue

QingAn: we can collect opinions and update the white paper

QingAn: is that OK?

tomayac: yes

https://www.w3.org/community/webextensions/

xiaoqian: when tomayac mentioned PWA was not good enough on iOS
… I wondered if the new WebExtensions CG will make PWA better
… also do you think the miniapp CG/WG should pay attention to the WebExtensions CG?

tomayac: this is a question that takes a lot of time to answer actually

tomayac: extensions can add features to browsers

tomayac: with iOS and iPadOS 15, Safari Web Extensions are available on all Apple devices that support Safari

tomayac: but you couldn't use an extension to use Bluetooth capabilities today

tomayac: I think extensions are not enough

QingAn: I enourage MiniApp vendors to add your opinions to the issue
… we can update the white paper

https://github.com/w3c/miniapp/pull/167

QingAn: any comment on this issue?
… we can keep this issue open and discuss on GitHub

AOB

<martin> https://github.com/w3c/miniapp/issues/160

martin: UI components
… we need to keep discussing this
… this is related to the Packaging spec
… templating options for MiniApps
… just a reminder
… MiniApp vendors please comment
… will affect the MiniApp Packaging spec

QingAn: one question for UI components
… is the idea to be based on web components or define some XML schema?

martin: we have two possible directions
… one is to reuse existing browser technologies as much as possible
… the other is to use an XML based solution
… some components in Open UI may overlap with our work
… we need to look at their work

QingAn: @@

Next teleconference time

<martin> +1 July 15

July 15, same time

Summary of action items

  1. martin to open an issue for lifecycle #8 in the miniapp-packaging repo

Summary of resolutions

  1. start documenting this in the Packaging spec
Minutes manually created (not a transcript), formatted by scribe.perl version 144 (Tue Jun 15 16:13:31 2021 UTC).