nastool 本身应该为插件提供前端组件，一种简单的，制式组件。插件返回页面布局描述，由 nastool 本身组装成真正的页面。
插件的路由统一用 /module/:pluginid/作为前缀，可以自由追加路由。

在插件管理列表，可以设置将插件固定到侧边栏，或者首页常用

#nastool

今天稍微思考了一下插件架构应该怎么设计……

我的场景是这样的：主程序是个 nas 管理工具，需要通过插件来扩展功能。比如下载插件负责下载文件，元数据插件负责处理下载完的媒体文件信息，字幕插件去找字幕。这些插件之间可以互相配合，但也可以独立工作。

所以插件系统需要：
1. 每个插件都要能说明自己能做什么
2. 插件之间要能发布和订阅事件
3. 长时间任务要能反馈进度

经过一番思考，整理出了这样的接口规范：

# 每个插件必须实现的基础接口
@dataclass
class PluginInfo:
    id: str          # 插件唯一标识
    name: str        # 插件名称
    version: str     # 版本
    description: str # 描述
    author: str      # 作者
    homepage: str    # 可选，项目主页

@dataclass
class ActionParameter:
    type: str
    description: str
    required: bool
    default: Any = None

@dataclass
class Action:
    description: str
    method: str      # GET/POST/PUT/DELETE
    path: str
    params: dict[str, ActionParameter]
    returns: dict    # 返回值描述

@dataclass
class Event:
    description: str
    schema: dict     # JSON Schema 描述事件数据结构

# 基础 HTTP 接口
GET /plugin/info -> PluginInfo
GET /plugin/capabilities -> {
    "actions": dict[str, Action],
    "events": dict[str, Event],
    "subscriptions": list[str]
}
GET /health -> {"status": "ok" | "error"}
POST /events -> 接收订阅的事件

然后拿下载插件举个例子：

# 下载插件接口定义
POST /actions/download {
    "request": {
        "url": str,
        "save_path": str,
        "headers": dict[str, str]  # 可选
    },
    "response": {
        "task_id": str,
        "status": "started"
    }
}

GET /tasks/{task_id} {
    "response": {
        "task_id": str,
        "status": "downloading" | "completed" | "error",
        "progress": float,  # 0-100
        "speed": int,      # bytes/s
        "downloaded": int,  # bytes
        "total": int       # bytes
    }
}

# 事件定义
events = {
    "download.completed": {
        "task_id": str,
        "file_path": str,
        "file_size": int,
        "mime_type": str
    }
}

这样的设计既简单又灵活，用 HTTP + JSON 的方式也让插件开发没有语言限制。每个插件都是一个独立的 HTTP 服务，主程序只要调用这些 API 就行了。

插件之间的协作通过事件来完成，比如下载完成时发个事件，元数据插件订阅这个事件就能自动开始处理文件，处理完再发事件给字幕插件……

而用户通过 nastool 的插件管理页面，设置插件的订阅事件，以及如何提取所订阅的事件里的参数映射到插件入参等等。

其实这个配置过程还是不够人性化，有点废手，可以考虑以 mcp 的形式提供，由 ai 来决定怎么填充！

想到这里，感觉这个方案还不错，先这样吧 😋

#开源项目 #nastool

接下来先把文件浏览器重构成 opendal #nastool #开源项目

今天已经把多进程架构实现了，也干掉了热重载和 win 托盘这些累赘。
写多进程的时候一直在思考怎么更优雅地信号控制子进程退出以及控制全局变量的实例化时机，令我想起了18年写 PHP 多进程的日子。

现在突然想到一些新的点子，以前一直很想要的:
1. 视频转音频
2. 音频转文字
3. 文字自动适配成字幕。另外支持按作品设置一些专用字典保持翻译一致性等

#开源项目 #nastool

对于 nastool 的后续改造计划一

1. 由于 GIL 的存在，即使 twisted 线程池也无法真正充分利用多核心并行，所以打算用多进程+reuseport 的方式其多个 twisted 进程
2. 然后我意识到像配置监听热重载以及写入对于多进程来说是个阻碍
3. 我的部署场景是只考虑支持容器化，实际上不需要热重载和源码升级重启这些能力，应该将这些部分清除，既可以减少累赘，也可以扫除多进程的障碍
4. 新的架构应该是，首先一个主进程，负责初始化数据，然后启动多线程背景任务，接着管理分叉多个 twisted 子进程等待。各自的子进程并行利用多核优势进行网络请求的处理响应

#开源项目 #nastool

发布了第一个 alpha 版本镜像

ghcr.io/yuchanns/nastool:v2.10.0-alpha.2

#开源项目 #nastool

功能上暂无什么实质性的变更，主要改动了:
1. HTTP 运行时从 flask 自带的 demo 改成使用 twisted
2. 调整了项目布局，以便于优化 Dockerfile 的构建流程
3. 为代码添加了 ruff format 和 lint 并通过验证
4. 打包镜像时限制了最小权限提高安全性
5. 增加开发脚本，优化了开发时的体验
6. 采用 PDM 管理依赖

GitHub

GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.

记录一下 fedora zram 如何调整:
1. 安装配置生成器

sudo dnf install zram-generator-defaults

2. 创建配置文件`/etc/systemd/zram-generator.conf`并写入:

[zram0]
zram-size = min(ram, 4096)

3. 重启 zram 服务:

systemctl restart systemd-zram-setup@zram0

#linux

刚刚发现原来 nastool 的原作者开了个新坑 https://github.com/jxxghp/MoviePilot

😂不过我还是决定基于原来的 2.9.1 分支继续开发我想要的版本，因为我感觉到了乐趣
#开源项目 #nastool

GitHub

GitHub - jxxghp/MoviePilot: NAS媒体库自动化管理工具

NAS媒体库自动化管理工具. Contribute to jxxghp/MoviePilot development by creating an account on GitHub.

看了一下似乎 ruff 对 mypy 的支持也在路上了
typecheck 先放着不管，等后面再修吧

https://x.com/charliermarsh/status/1884651482009477368

#开源项目

X (formerly Twitter)

Charlie Marsh (@charliermarsh) on X

We’re building a new static type checker for Python, from scratch, in Rust.

From a technical perspective, it’s probably our most ambitious project yet. We’re about 800 PRs deep!

先把仓库建起来，并作了 pdm 的适配，对目录进行了改造。
修改了 Dockerfile 移除了一些没用的功能脚本。把基础镜像改成了 debian。

说到镜像，很多人都会像原项目这样喜欢选 alpine 图绝对小的体积。其实比起绝对体积，相对体积更重要。选择一些例如 debian 或者 ubuntu 这样预设了丰富的工具的镜像你自己改造的中间镜像层就会比较薄。利好其他镜像重复使用基础镜像

此外添加了 ruff lint format，还有 mypy typecheck 。不过目前 typecheck 有太多不通过的地方了😅慢慢改

https://github.com/yuchanns/nastool

#开源项目 #nastool

nas tools 增强计划

nastool 2.9我用了有两年左右，有些功能年久失修，有些在使用上也不能满足我的需求。今天我突然想到自己是不是也可以继续在这个基础上开发维护呢？

先定下几个想法:

1.切换到 twisted
2.识别失败的 unknown 数据接入 mcp 提供给 ai 做 tmdb 查询
3.异步化改造
4.对订阅源支持可指定固定 tmdb id 而不是每次识别
5.存储层切换成 opendal
6.设计一个插件架构，保留核心，剥离其他功能成为插件

#开源项目 #nastool

将镜像迁移到 ghcr.io 后发现 shields 缺乏一个展示 ghcr badge 的功能。实际上我在评论区找到了一个替代品，但是用了一天它就挂了。
于是用 Sonnet 3.5 + avante 参照源码快速手搓了一个 Cloudflare Workers 的实现😋 #vibecoding

https://github.com/yuchanns/ghcr-badge-worker

GitHub

GitHub - yuchanns/ghcr-badge-worker: A lightweight Cloudflare Worker implementation that generates beautiful status badges for…

A lightweight Cloudflare Worker implementation that generates beautiful status badges for your GitHub Container Registry images. - yuchanns/ghcr-badge-worker

非常喜欢 twisted 这个框架，给我一种 solid 的感觉。使用它，除了总网关外就不需要再另外配置 http server 。比起生命周期短暂的脚本，我更喜欢这种常驻内存的进程。一如 PHP 的 workerman
最近改造一个网友的 wxocr 项目也使用了它，压测的感觉非常强大！
https://github.com/yuchanns/wxocr

GitHub

GitHub - yuchanns/wxocr: x86 and aarch64 support

x86 and aarch64 support. Contribute to yuchanns/wxocr development by creating an account on GitHub.

AX6S 老断流，实在受不了刷个纯净版治好了

国产路由这些年都塞了什么乱七八糟的功能进去啊……

1. 教程 https://right.com.cn/FORUM/thread-8216670-1-1.html
2. 纯净固件 https://right.com.cn/forum/thread-8258192-1-1.html
3. 救砖备用 https://right.com.cn/forum/thread-8261401-1-1.html

尽管浏览过很多次 itch.io 但今天是第一次注册了一个账号。并且在 LOVE2d 区看到了一个完整的开源游戏，在此记录一下日后可以学习: https://gitlab.com/stone-kingdoms/stone-kingdoms #gamdev

GitLab

Stone Kingdoms / stone-kingdoms · GitLab

A real-time strategy game made with LÖVE based on the original Stronghold by Firefly studios.