scrapbooktools icon indicating copy to clipboard operation
scrapbooktools copied to clipboard

來蹭一波大神~

Open danny0838 opened this issue 4 years ago • 2 comments

大神好,我是 ScrapBook XWebScrapBookPyWebScrapBook 的開發者,總之是各種改良和強化已太監的 ScrapBook 的重造輪字愚蠢工程,比如修復臭蟲、改良資料結構、支援遠端存取、全文索引、靜態站台輸出等等。

無意間看到原來比我早以前就有大神在做相關工具了,來膜拜一下,也許之後可以把這些東西整合起來做更全面的應用~

danny0838 avatar Oct 06 '20 08:10 danny0838

@danny0838 是也乎,( ̄▽ ̄)

俺只是头大妈, 你才是大神, 相比你能参考 ScrapBook 原有代码, 拓展出自己想法的插件来,

俺只是老老实实在持续使用而已, 中间也用过一段时间 ScrapBookX 和原有数据非常兼容, 感谢;

但是, 一切在 FireFox 56 之后变化了:

  • 嫑升级 FireFox 到 56 以上 ~ DebugUself with DAMA ;-)
  • 但是, 后来 FireFox 强行升级, 不得不迁移到 WaterFox,
  • 最近 WaterFox 也不得不升级到不兼容老 FireFox 插件体系框架了
  • 导致俺现在只能用 WaterFox 2019.12/64-bit 使用老 ForeFox 系列好用插件
  • 用 Edge 来访问国内资源, 用FireFox 来访问国外资源, 最新 FireFox 来用 Tree Style Tab 管理工程页面...

其实, ScrapBook 发源日本的手帐习惯, 对网络/网站/服务/...的不信任, 导致:

  • 尽可能将原始页面下载到本地
  • 自然的希望使用树状结构来管理
  • 进一步的, 在长期使用过程中, 又希望可以灵活的根据经验/知识经验的增长来调整这颗树
  • ...

俺也是在长期使用过程中, 才慢慢理解 ScrapBook 提供的各种能力是来解决什么场景中的什么问题.

俺唯一拓展的, 不过是在本地 ScrapBook 数据目录基础上, 如何快速发布/分享自己收集的所有网页;

从俺整体经验来看:

  • 0: ScrapBook 原始功能/设计非常科学, 足够解决网页笔记这个命题所有主要问题
  • 1: FireFox 向 Chromiun 体系投降后, 插件体系也遭到彻底破坏,
    • 原先 XUL 技术框架下可以对本地文件进行操作的权限被完全阉割后,
    • 如何安全/快速/大量对本地文件进行操作, 需要重新设计/恢复;
    • 俺的直觉可能要依赖外部工具,
      • 比如 Alfred/GhostText 那种通过标准临时 http/udp 服务
      • 来提供专用数据/指令通道, 来替换由 JS 直接从浏览器向 OS 给出文件操作
  • 2: 网页笔记光本地使用, 慢慢的也就没了动力, 可以快速组织为网站发布, 通过 7牛 之类CDN 服务可以快速发布海量网页数据;
    • 其实也就变成了私人网络资源整理,
    • 只是现在看俺的简单粗暴发布, 少了个关键能力,
      • 将原始链接, 合理附加在发布出来的网页片段页面中,
      • 这在尝试过程中发现, 没办法简单插入到原始网页中, 因为 CSS 不同, 无论插入到哪儿, 都可能产生混乱
      • 所以, 可能的办法:
        • 设计一个通用 CSS 效果,随原链接插入到每个页面 </body> 之前
        • 上页面框架, 将原始链接以及工具状态之类私人附加信息用 frame 框架页面专门发布
        • ...

总之, ScrapBook 原先的设计是非常精准和有效的, 这么长时间的维护又真正完备了自身.

俺从05年开始坚持使用,到今天; 收到了 36G 左右网页数据; 发布在: ZoomQuiet.io -> collection {by gen4dot2htm.py vv.190718 at:190911 18:13:08,805091} https://zoomquiet.io/collection.html

ScreenShot 2020-10-06 17 45 37

唯一遇到的问题就是当对应收集超过1万个目录时, 搜索之类遍历操作, 经常会卡死, 这也是为什么后来不得不分库分 book 的原因.

这个问题应该必须将直接对硬盘目录/文件的读取,变成向专用索引数据库查询来解决. 直觉上 SQLite 是最自然的选择, 但是, 参考微信也使用 SQLite 一样在数据超过8G 之后, 就有各种问题, 所以, 不知道 ScrapBook 如果将所有数据都收纳到 SQLite 中, 是否能比,直接硬盘文件能更好更稳定长久的使用...

综上, ScrapBook 是个非常稳定和优良的笔记形式和方案; 但是, 随着 FireFox 的自我放弃, 这个工具如果变成独立软件, 将失去一切优势, 堕落为劣版 Everynote,

所以, 怎么继续发展, 还得看诸君努力,

俺唯一期待就是, 可以兼容 ScrapBook 原始数据格式, 可以一键导入.

ZoomQuiet avatar Oct 06 '20 09:10 ZoomQuiet

平台問題目前 WebScrapBook 算是有初步解決了:

  • 瀏覽器套件相容 Fx 和 Chromium 體系。後端是 Python3,相容性問題應該沒那麼多。未來或許可以把更多管理方面的功能改為基於 Python 後端,以便不安裝瀏覽器套件也能管理內容。
  • 資料結構延續 ScrapBook,但也做了不少改良,例如目錄樹由單一 rdf 檔改為多個 js 檔。檔案仍是以 plain file 為主,可以很容易發布為靜態站台。
  • 最近終於完成了轉檔工具,一個指令就可以把 ScrapBook 轉為 WebScrapBook 格式。
  • WsbScrapBook 對於分 book 有比較好的支援,可以輕易實現跨簿搜尋和定位。目前還沒試過高達 36GB 數據的搜尋,不曉得現代硬體和瀏覽器撐不撐得住,不過最起碼可以做到把單簿資料量減少、一次不要跨太多簿搜尋。
  • 目前全文搜尋還是比較愚蠢的下載至客戶端處理,流量開銷比較大,未來或許可以實做後端 python 搜尋,效能應可再提升。
  • 全文檢索快取改用 SQLite 實做也是個方法,但這樣就無法直接支援靜態站台,需要再研究研究。

danny0838 avatar Oct 06 '20 11:10 danny0838