y2361547758
commented
4 years ago 当有多个组接入同一fridge实例时，必然可能出现因为转发或引用关系（甚至是因为监听同一个推主），多组烤同一个推。出于对翻译的尊重上面原始设计里直接隔离了各组的翻译文本，各干各的避免互相污染，但如果把这条限制去掉，这个平台就有更多的可能性了。
本着知识共享精神，分享翻译能够避免重复劳动，而且本平台也是为了发布翻译而设计的。如果记录下发布链接，也方便它组纯文本复刻。（不过目前只能使用Rsshub监控B站动态，更新频率也很低，另外目前不能跟踪纯文本翻译发布，总之先写这）
koishi-app
增加设置，是否尝试获取他人翻译、是否允许别人获取自己的翻译。
增加命令，查找它组翻译并返回（翻译文本，发布地址）；更新推送时同时尝试查找？
fridge
任务表published自动改为string类型，记录发布链接。
租户表增加两个配置……害，tenancy表还没设计呢
oven
增加参数，是否读取它组的翻译，始终优先使用自己的翻译
题外话
将oven设计成分布式的，并写一个纯前端终端，只要开着界面就能ws接入分摊烤推压力（？）如果有登陆甚web console至可以优先烤所在租户的烤图任务（x
web console
总之两个配置提示写好
开源后的重构计划
由于maid需要使用Twitter的API，而使用API的KEY申请不易，部署一个新实例变得十分困难；自用还好说，让其他人使用的门槛有点过高了。
那么要解决这个矛盾，改进的方案如下：
以下是我的设计草稿
maid - 监听器
从数据库获取需要监听那些推主，推尽管往数据库塞，有更新仅需推送给app一次。
新接口：触发更新监听列表
监听列表实现(?)bot专用推特号，关注所有需要监听的推主，然后监听自己时间线
koishi-app - Bot
从数据库获取配置，动态注册koishi配置(?)，被动重启以加载租户变更(?)
单独watcher实例，监听maid的更新推送，然后找到对应koishi实例触发推送
如果koishi-app也多实例，需要平衡多个实例直接的配置数量（使用本地coolq和自带coolq的分开？），maid也要推送到所有实例
监视运行状态略麻烦，每个koishi实例定时向数据库/文件汇报，根据最后更新时间判断在线，在线获取日志？
frige - 数据库
加一张任务表，将部分字段从推文表移至任务表；
taskId & tid & tenancyId 唯一，为了避免用户使用的id不连续，taskId在条件内自增
有推文入库（推文表）时，按租户订阅，插入到任务表；取队列时也从任务表取（而不是原来直接从推文表取）
oven - 烤图机
新前端接口(Web interface)
后端重构弃用wkhtml2image，使用headless Chrome/Firefox;
单独chrome进程实例，多图同时烤时用同一个chrome，队列限制同时烤图数，chrome闲置一段时间退出(?)
新模块 Web console
管理租户
用户管理，注册登陆、会员充值(?)
租户管理，新建消除、修改配置
可能用得上的配置：监听推主(列表)、监听发布渠道(列表，如B动态/微博等)、cqhttp地址(本地实例)、工作群号(列表)、推送群号(列表，通常同工作群)、是否允许私聊/好友上班、*附加插件参数
(带*的可以设计为高级用户特性)
在线任务表管理
针对租户，在线koishi-app功能实现，主要方便批量删藏任务
接入方法
在web上注册用户，新建一个租户后，按配置自带coolq+cqhttp带外网，用ws/HTTP正向接入
或使用我们提供的coolq实例(?)