Enhanced features for Paperlib

[ultranity]

Paperlib 是一个很酷的项目，但与 Zotero 相比，缺少了一些功能，在此列出作为可能的改进建议/开发项

• 缺少子项目，难以支持多附件 [Feature Request] Show sup file name #177，可考虑将paper entity重构增加子item，进而甚至可管理多个在线源
• 网站快照 chrome extension有计划支持网页内容导入吗？ #186，可考虑 利用mht或将网页导出为 markdown
• 直接在详细页面编辑元数据 I want alias support QAQ! #394
• 排查重复文件 [Feature Request] Detect duplicate articles #205
• 文件回收站
• 管理参考和关联文献
• pdf阅读，预览窗口可用但可以更好用？
• 笔记/高亮/注释，或与obsidian等外部笔记工具联动方案。鉴于直接在pdf上注释会修改源文件增加文件同步难度，当前是否有管理文献笔记增量同步的best practice? 已知zotero的方案是存储为itemAnnotations在pdf viewer上增加渲染
• 内容搜索索引，适合于配合AI summary/pdf阅读
• 文件夹存储，有助于脱离paperlib时使用，但增加数据库管理难度
• arxiv comments/ semantic scholar TLDR, 适合作为子项目

以及有一些希望实现的功能：

• 监控 arxiv 版本更新，配合多附件、arxiv-diff更佳
• python sdk/api client，配合内容索引和AI甚至能升级为第二大脑PKM like https://github.com/reorproject/reor
• 移动端（pad），当然这会是个大工程

我正在了解paperlib的代码结构，但工作原因只有部分业余时间可以参与开发，希望 Paperlib 可以不断迭代完善替代 zotero，期待得到意见反馈和可能的功能开发帮助 ：)

[GeoffreyChen777]

1. paperlib 的设计理念不同，paperlib 面向论文书籍等科研文献，并且永远是这样。里面存储的所有东西都是论文。尽管也许有用户想要存别的东西，但是这不是 paperlib 想做的。因此每一个条目都必定存在一个主文件，也就是主论文。以及该论文所包含的各种补充文件，比如源代码等。因此，在将补充文件拖入一个论文的右侧详情列表的时候，会添加为附件。而不是像zotero那样和主pdf并行。
2. 现在的插件系统理论（hook 类插件）上是可以实现这个功能的。软件主体应该不会去实现这个。因为很多用户不需要保存网页。建议使用插件实现。
3. 这个牵扯到 ui 组件的问题。并且 paperlib 尽量想为每一个论文精准匹配元数据，也就是并不需要手动更改。如果你的学科大量论文无法准确识别，那么可以在此留言，需要的数据库。需要适配。
4. 理论上是不会有重复文件的。重复的添加不进去。
5. 回收站也许会做，但优先级不是很高。
6. 关联文献牵扯到 pdf 的解析（离线）或者 API 比如 semantic scholar。同样期望使用 new window 类型插件实现。软件主体希望尽可能简单。
7. 应该不会做pdf阅读器。因为我个人是博士生，精力有限，无法做到在维护软件主体的同时，还能做到比现有的专业pdf阅读器还好用。因此 paperlib 只注重于文献管理。读的事情交给专业的阅读器。
8. 这些东西，paperlib 并不参与。这是外部pdf阅读器的事情。和其他软件联动参见插件市场里的 api-host。
9. 现在就有全文缓存，在 cacheService 里。
10. 现在就支持自定义文件夹存储层级格式，参见设置里面的 renaming format。
11. 同样，不是所有人都需要这个，因此建议放入 UI slot 类型插件实现。

—-

1. 同样可以插件实现。
2. 参上。不需要各个语言的sdk，现在用 api-host 插件，通过 http 就可以交互了。
3. 几乎不可能。我的精力无法做到维护电脑版本和pad版本。

—-

综上所述，paperlib 的设计理念是简约，且专注于科研文献。有时候，功能，简约，臃肿，需要做出取舍。

因此在 3.0 重构了整个代码引入了插件系统。大部分不是所有人都需要的功能，最好用插件实现。用户按需下载。