n-ext版本的开发目标

[Gaubee]

​架构层主要将围绕这几个方面：

1.​ 彻底进行前后端分离：
2.​ 后端的内核部分，完全使用rust进行重构，使得内核能适用于更大范围的领域，包括鸿蒙、pureweb；
3.​ 前端部分，开发dui框架，使得各个平台分离独立，dui是低入侵的，它可以逐步替代手写的原生代码。

​标准层主要围绕这几个方面：

1.​ 更好的可访问性。本质是gui与txt的双向绑定，从而为AI的自动化提供基础。
2.​ 多设备协作，构建多设备互联的标准。从局域网互联出发，再到广域网局域化。可以从团队需求入手，我们有时候打包就需要调用其它架构的设备进行打包，那么就应该有一个bash.desktop.std.dweb模块，来在一个设备上指挥多个设备执行打包命令。
3.​ 推进模块的静态文件路径标准，使得模块没有启用就可以提供文件服务。该标准目的是为了给所有模块提供一个file.std.dweb的子协议。而系统的文件系统应该是file.sys.dweb。该标准可以用于一些资源型的模块；模块之间的文件访问无需走ipc-request，性能更高，特别是plaoc这种需要大量静态资源的场景；还有模块之间的文件picker

​应用层主要配合底层进行重构，如果底层因成本难以暂开，那么应用层需要至少完成这几个部分的工作：

1.​ 基于现有架构进行更好的前后端分离。虽然目前仍然都是基于kotlin，但需要开发者自己付出心智负担，来制定更加严格的开发标准。
2.​ 移除changeset、changemap、signal、observerProps等原有的临时方案，更大规模地使用flow或者easyflow替代相关需求。（ps：easyflow是模拟flow接口的一个最简子集，主要作用就是委托，但具有更好是可调式性，参考ts版本的实现。）
3.​ 完成downloadManagementNMM
4.​ 桌面使用原生开发，图标使用静态资源
5.​ 对接webauth标准，实现auth.std.dweb模块，以及对应的authManagementNMM
6.​ 实现存储管理，在模块有了独立的file.std后，jsmm的文件不再依托于jmm提供，而是原生提供。特别是需要对dwebview的数据进行更加规范且统一的管理。数据的删除不再依托于plaoc的setupdb插件，而是做标准化管理。从而在卸载的时候可以告知用户是否移除数据；或者用户可以自己到nmm中进行数据管理。
7.​ 实现notification以及对应的NotificationManagementNMM
8.​ 强化与宿主系统的适配。提供桌面小组件；适配画中画，全局浮窗；更好的视频播放下载体验。