[Feature Request]提议优化OpenWrt-mihomo项目结构以增强模块化和灵活性

[Mikihta]

问题描述

当前，OpenWrt-mihomo项目主要由mihomo（内核）和luci-app-mihomo两个插件组成。然而，mihomo内核插件包含了许多应由luci-app-mihomo处理的高层功能（如DNS劫持和防火墙配置），导致两个插件高度耦合。这种设计模式增加了用户在更新过程中的操作复杂性，并且影响了项目的整体可维护性。

观察到的问题

• mihomo和luci-app-mihomo之间的功能重叠导致必须同时更新两个插件以实现效果。
• 高耦合度使得维护和升级过程复杂且易出错。

建议的改进

1. 核心内核分离：建议将mihomo插件专注于核心网络功能，例如添加到系统路径的内核文件（类似于Adgurad home、SingBox），而将DNS劫持、防火墙设置等高层功能迁移至luci-app-mihomo。
2. 独立项目：考虑将mihomo插件作为一个独立的内核项目维护，这将有助于吸引对核心技术感兴趣的开发者，并鼓励更多基于此内核的创新实现。

预期好处

• 降低耦合度：使插件更专注，简化更新和维护过程。
• 增加灵活性：用户可以根据需要选择安装不同的功能组件。
• 鼓励社区贡献：模块化的设计可能吸引更多开发者参与。
• 提高可维护性：降低维护成本，加快错误修复和功能迭代的速度。
• 促进标准化：标准化的模块化设计促进生态系统的健康发展。

结论

希望这些建议能被考虑，以改善OpenWrt-mihomo项目的结构和用户体验。期待您的反馈和项目的未来发展。

[Mikihta]

将mihomo内核插件作为一个独立的项目后，更有利于实现对alpha版本的mihomo内核更新（作为pre-release版本发布），能为用户提供更多的选择性。

[morytyann]

核心内核分离

我还是坚持我的想法，我想以官方的方式来做这个插件，既service/luci-app/luci-i18n三个包，service用于运行服务，luci-app用于配置服务，luci-i18n用于luci的本地化。

独立项目

如果是在上一条的基础上，那这个包就没有什么意义了，会写Makefile就可以做出来。或者可以按OpenClash的方式，下载二进制文件也可以呀；如果不在上一条的基础上，那就和上一条冲突了，还是说你的两个建议是或者的关系？