luci-app-xray
luci-app-xray copied to clipboard
yichya
它工作的很好。依赖很少且代码简洁体和人小巧。但可能会增加一个主开关吗？
试了下用启动项来管理总开关也挺好的。而且逻辑上也很合理。 倒是可以在xray界面显示显示下进程的runing状态，因为现在从luci界面，不管是xray还是进程管理，都不能检查进程有没有跑成功，要ssh到后台查看。然后既然要检查和显示进程有没有在run，可以顺便检查下代理是否真的成功了，并把结果传回luci界面。不知道这样会不会增加依赖或者加过多代码。现在openwrt下支持xray的luci app很多，但这个是代码最小的，像极了luci-app-shadowsocks-libev。既然xray已经进op官方软件源了，感觉luci-app-xray也应该进。
倒是可以在xray界面显示显示下进程的runing状态，因为现在从luci界面，不管是xray还是进程管理，都不能检查进程有没有跑成功，要ssh到后台查看。
这个不难整。
然后既然要检查和显示进程有没有在run，可以顺便检查下代理是否真的成功了，并把结果传回luci界面。
这个比较麻烦，要么整定时任务，要么整 rpcd，都会比较慢，而且真的出问题的时候不如直接看 System log 直接一些
现在openwrt下支持xray的luci app很多，但这个是代码最小的，像极了luci-app-shadowsocks-libev。既然xray已经进op官方软件源了，感觉luci-app-xray也应该进。
luci-app-xray 主要是自身目前还没完全稳定下来，尤其是 DNS 和路由都写得比较简单（也就是说可能过段时间有可能会进行一波大改），而且它跟官方源里面的 xray-core 在 init 文件上有冲突，如果要放进去的话还需要一段时间的迭代
听您这么说的话，我觉得判断running状态可以加，代码简单耦合性低，在初始设置和日常使用的时候都挺有意义。(主要是看到一个绿色的running会给用户莫名的安全感，用户逻辑上也特别急需这个） 什么定时任务、rpcd就算了，只听这些名字就知道写出来的代码一定很丑陋。后期迭代到细琢的阶段，可以放个按钮，用户需要的时候手动点击check代理有效性。然后这个check按钮最好不增加依赖。如果必须增加依赖的话，就让软件包build和install的时候不显式依赖，直到用户需要使用这个功能时再提示安装依赖。哈哈，我也不知道在一台1天2度电的洋垃圾工作站物理机上运行op这么抠是图啥。。。
听您这么说的话，我觉得判断running状态可以加，代码简单耦合性低，在初始设置和日常使用的时候都挺有意义。(主要是看到一个绿色的running会给用户莫名的安全感，用户逻辑上也特别急需这个）
已经加了，但不是绿色的，样式回头再说吧或者可以自己改然后提个 pull request（
后期迭代到细琢的阶段，可以放个按钮，用户需要的时候手动点击check代理有效性。然后这个check按钮最好不增加依赖。
依赖倒是不需要，rpcd + uclient-fetch 就够了，可能回头有时间搞 rpcd 模块的时候会弄