PUG 已废弃,设计文档仅供参考。
本文档是关于自动搬运系统 PUG 的设计文档,在一定程度上消除了先前讨论中的术语分歧,并试图以简单易懂的方式解释整个系统预计的工作流程。
PUG
PUG
pug
:本体,负责主体逻辑。pugc
:Electron 客户端,负责在个人使用时提供简单易用的用户界面。pug-web-extension
:浏览器插件,负责在浏览器段提供易用的用户界面。pugw-frontend
:前端页面,负责与服务器上的后端对接,提供托管的搬运业务。该项目属于多人课设项目(据说),并计划将该项目的界面应用到其余两个客户端中。
同时,因 PUG 而废弃的项目有:
[u2b](https://github.com/Yesterday17/u2b)
:试图自动搬运YouTube
视频到bilibili
的项目,其功能是 PUG 的子集,故废弃。[bili-archive](https://github.com/Yesterday17/bili-archive)
及其衍生项目(包括[bili-archive-frontend](https://github.com/Yesterday17/bili-archive-frontend)
、[bili-archive-helper](https://github.com/Yesterday17/bili-archive-helper)
、[bili-archive-report](https://github.com/Yesterday17/bili-archive-report)
):其功能相当于从 bilibili 搬运视频到本地,功能亦为 PUG 的子集,故废弃。
值得注意的是,虽然该项目的起因是搬运视频,但设计中并没有局限于视频本身。理论上只要有模块支持,PUG 也能完成自动诸如搬运推文等非视频性工作。
总览
下面我们给出一张单个 Work 工作的流程图。这张图看起来可能有点像固定管线,但其实这些分块只是为了描述这条 Workflow 的工作流程而做出的人为划分,实际过程中并不存在强制的步骤关系。
我们注意到,我们称整个工作为一个 Work,工作在 Workflow 中运行,因此这张图描绘的是 Workflow 的一个缩影;图中右边四列都是 Pipeline,而 Workflow 就是一个从左至右的过程,这表明了一个 Workflow 的设计意图是用来完成一种任务,本质不同的两类任务应该分成两个不同的 Workflow;代表 Pipeline 框中有许多蓝色的 Pipe,这表明了 Pipe 应该是用来完成某一项具体任务的最小单位。
针对 Pipe,我们的单位是“节”;针对 Pipeline,我们的单位是“条”;针对 Work,我们的单位是“件”;而针对 Workflow,我们的单位是“个”。
整个理解过程中,如果你有不明白的地方,可能需要多次回来观察这张图片,这张图片描绘了 PUG 运行的基本流程。下文为了简单期间,会将这张图简称为总览图。
Pipe
正如上文所说,Pipe 是完成某一项任务的最小单位,这是狭义的 Pipe 定义;从广义上来说,Pipe 是整个系统中的通用结构单元,Pipeline 和 Workflow 本质上也是 Pipe,只不过其并不满足狭义上 Pipe 的定义。当然了,广义上的 Pipe 属于实现细节,在后文的叙述中,如无特殊说明,Pipe 一般均指狭义上的 Pipe。
把任务拆分成 Pipe,也就是为最小单位,是有原因的。设想下面这种情景:在一个 Workflow 中,我们可能需要多次登录某一网站。登录的目的是为了重新获取被注销的用户账户的用户凭据,因此在每次用户登录失效时都需要重新登录。那假如我们将登录的任务和上传的任务实现在了一起,那么我们就无法完成单独的登录功能了。
上面的案例对应的是总览图中的最右边一列,图中对应用户账户登录失效的处理措施是用户干预,而用户干预的一般用途是要求用户输入对应的凭据,即用户名和密码。在用户干预完成后,势必需要登录操作,因此将登录操作单独拆分称 Pipe 是有必要的。
Pipe 是没有状态的,它的状态由上层管理,其本身只存在属性。属性代表了 Pipe 的基本性质,一般情况下不应该发生改变。
Pipeline
Pipe 的功能的确很细致,细致到我们常常不需要那么细致的操作,因此出现了 Pipeline。一条 Pipeline 对应的是一些 Pipe 的组合,它组合了这些操作,并成为了高一级的复用单元,我们称 Pipeline 是用户态的复用单元。
还是以上文的登录情景为例:验证用户凭据是否有效很显然是一个 Pipe,而需要用到用户凭据认证的情况有很多,除了无效时重新登录之外,还有很多有效时的操作,如获取 Timeline、获取关注列表等,而每一个上述的操作都会用到验证用户凭据这一节 Pipe。这时候,我们就可以将验证用户凭据的 Pipe 和对应的操作 Pipe 组合成一条 Pipeline,以便在 Workflow 中使用。
这里可能会有读者对 Pipeline 的功能表示不解。确实,在简单流程下 Pipeline 的作用可能不大,但当 Workflow 存在非线性流程,或存在多个 Workflow 时,其可能就会需要复用一些相同的单元,而 Pipeline 就代表了这样的复用单元。
此外,Pipeline 的用户态复用性还意味着其可以作为一个处理部分被打断,被打断后,Pipeline 不会保存其中的任何内容,相当于该 Pipeline 未被执行。
和 Pipe 一样,Pipeline 也是没有状态的。
Workflow
Workflow 是多条 Pipeline 按照一定逻辑执行直至结束的流程体现,大多数用户态的操作都针对 Workflow 完成,比如输入、暂停、中止等。此外,全系统的状态也由 Workflow 管理。
为了控制 Workflow 的流程,我们计划引入一些特殊的 Pipeline。区别于普通的单输入单输出的 Pipeline,它们可以拥有复数输入复数输出,以完成特定的应用目标。(draft)