像 Jmm 这种 Service 同时要有 Application 的逻辑，应该如何更好地设计？

[Gaubee]

目前我们使用gui.jmm.browser.dweb这样一个独立的 mm 来代理委托jmm.browser.dweb的 gui 显示功能，这其实很别扭。

这里本质的矛盾在：jmm 需要作为一个持久化服务提供能力；同时它本身又是一个 Application，而根据标准，所有的可视化窗口被关闭后，模块就应该被关闭。模块一旦被关闭，jmm 所能提供的服务就没了。

这里总结一下 jmm 的职责，同时给出一些评论：

1. 作为 jsMicroModule 的安装器，使用 gui.jmm 这个模块代理视图，然后向 dns 注册程序

   这点没问题，安装期间是有可视化窗口的，对于用户来说所见即所得。

2. 需要有所有注册的程序并且提供静态文件访问 file:///usr/*的路径

   如果 #112 的提案能被正确设计出来，那么每个 jsMicroModule 的文件访问就不再需要依赖 jmm，而是回归只依赖 file 模块即可

3. 在生命周期启动的时候将所有的程序进行注册，在生命周期销毁的时候关闭注册

   这点导致 jmm 需要作为启动程序，开机启动，除非让 dns 本身具有持久化能力，但这没有太多意义。

   如果不做“关闭注册”，反而会很奇怪，因为就要考虑重启怎么办？以及如果已经有正在执行中的应用，要怎么办？ 如果做了“关闭注册”，那么 jmm 就不能被关闭，否则所有 jsMicroModule 模块都会消失。

---

如果我们能有一个托盘程序，这样就可以不违背所见即所得的逻辑，桌面端也许可以做，但是移动端做这个就更加奇怪了，没地方放它，还得多一个悬浮区域？。

而且将一个 jmm 的 logo 放在托盘程序里头也很奇怪，因为这不是用户的主观行为。

---

或者我们可以在 windowProperty 中，给出一个新的属性，可能叫“keepBackground”，通常这个属性只能 desk 不开放修改，只能用户来手动进行修改，就像置顶一样。 但是 desk 可以将 jmm 的这个属性设置成 true，这样 jmm 的窗口在关闭不会被回收，还会保持后台运行。

---

另外我希望 jmm 能进一步变成 installer.browser.dweb，专门负责各种各样的模块安装：

未来我们还要有 remoteMicroModule、wasmMicroModule。

其中 remoteMicroModule 是特殊的，比方说在我的手机和电脑用同一个密钥再同可互联的网络下关联了设备， 那么我的手机理论上就可以用密钥要求我的 PC 打开某个程序， 然后这个程序提供 https-web-ui，从而我的手机可以通过 webview-window 来加载并显示它。 （接着通过 yjs 这种库让 PC 和手机协作在一起，在手机上编写的内容同步到电脑上，电脑作为服务端自动对其进行保存。这点需要另外开一个 issues 来讨论）

[Gaubee]

16cf69379