1.2.5 文件 (夹) 名称 ID 化,是否与本地化的初衷渐行渐远?

本贴最后更新于 1389 天前,其中的信息可能已经东海扬尘
  • 每次大本版更新,都是提心吊胆,因为新特性总是在负面影响甚至破坏已有的工作流
  • 1.2.5 最大的改动便是文件名 ID 化,这直接导致
    • 除思源外任何工具对思源文件的管理不具备可读性和可操作性性
    • 系统资源管理器几乎变为资源管理空气
    • 文件级,文件夹级拷贝分享变的异常艰难,以至不可能
    • 第三方同步盘的同步日志变得没有丝毫可读性,同样文件级的版本恢复变得异常艰难(特别是思源自身的同步仍然只能作为 plan B, 即便一直改进,应该也无法和专业软件(坚果云)比肩)
  • 对系统工具,对第三方工具的友好性,不正是本地化的一大便利么(另一大便利是安全)
  • 如果 ID 化是子文档的代价的话,那真是子文档的一个最糟糕的本地化实现,更何况子文档也丝毫不会对笔记带来本质的提升。纯在线的 ID 化无所谓,用户根本不关心这个。可用思源就是冲着本地来的
  • 特性的引入伴随思源一直在收紧自由度,从资源的统一管理到文档名的 ID 化,收紧的方向正常,但方法真是一言难尽
  • “思源用户不关心本地文件名,软件能打开就行”,但还是有一部分用户关心文件名的,越是深度用户越关心,随着笔记的数量提升,协作需求的提升,也许会有越来越多的用户看到这一串 ID 而苦恼吧
  • 实现同样的功能,应该有比文件名 ID 化更高效,更平和的实现吧?希望两位主创能考虑下这个问题
  • 思源笔记

    思源笔记是一款隐私优先的个人知识管理系统,支持完全离线使用,同时也支持端到端加密同步。

    融合块、大纲和双向链接,重构你的思维。

    25895 引用 • 107298 回帖

相关帖子

优质回帖
  • 88250 4 10 赞同

    你好,是时候和大家分享一些这方面我们的设计考虑了。

    从使用角度

    思源不是文本编辑器,而是知识管理系统。如果以编辑器的方式来使用,肯定会感到别扭的。

    • 同一层级下需要支持同名文档,这样能将新建、重命名、移动等操作的同名阻断问题降低,使用起来更流畅
    • 子文档形式比文件夹形式效率更高,能够充分利用文档树的空间,从概念上也统一为文档,减少不必要的实体
    • 分享和协作不是思源现阶段的目标,现在就这样用的话是肯定不会好用的,协作大概在 v3 阶段会开始设计

    从技术实现角度

    优先考虑稳定性。

    • 通过文件实现易变数据的互操作性是一个糟糕和错误的方向,因为多个进程各自直接读写易变文件有概率会导致数据损坏。概括一点讲就是试图通过共享文件、共享内存来实现互操作性的方案都存在一致性问题,正确的方案是通过 API 进行交互,各进程内自己保证一致性
    • 使用人类可读的文本在跨系统平台时存在大小写问题,比如 Linux 上允许同时存在 SiYuansiyuan 文件,但是 Windows 上则不允许,该情况一旦发生数据就可能会被损坏

    寻求平衡

    我们一直在寻求对普通用户和对社区开发者都友好的平衡点。

    • 对普通用户尽量屏蔽底层细节,所以思源迟早要覆盖一些在文件系统上的常规操作,比如批量移动、删除文档,最终目标是用户不必关心文件结构,专注于使用
    • 对开发者而言,需要的是稳定的方案,如果某个方案可能存在某个问题,那么这个问题一定会在将来的某个时候发生

    忒修斯之船

    思源这样一直更新下去,还是当初的思源吗?

    在发布 v1.2.0 的时候我们说过,如果没有更好的替代方案,不会轻易删除已有特性,这次变更我们觉得并没有违背这个承诺。

    一个产品如果没有明确的产品方向和架构思路,这个产品就算做到能用也不会是个好产品。至于个性鲜明或者说思路清奇的产品能否被用户接受,这只能用市场来检验了。好产品无需推广,烂产品就算被骂死也不会有所改变。

    最后,我们作为主创团队,直接劝退用户的话不太礼貌,然后还会有人说:“你看他们,傲慢得不得了,容不得半点意见”。但这样的评价并不重要,重要的是我们觉得浪费了大家的时间精力,与其忍着用,不如早点换。

    以上。

    @participants

  • programfan 2 3 赞同 via macOS

    说几点看法和期望:

    1. 如果关心修改历史,但又只关心文件名,这个只能说是“叶公好龙”。我不用思源的历史功能,也不用第三方同步的历史功能,自己建了一个 git 仓库,手工管理历史,清清楚楚。只要思源维持“本地 + 文本”这种技术路线,想要修改历史有无数种办法,为什么要纠结文件名?
    2. 如果确实对 id 和文件名的对应关系有需求,在 sy 文件里面有,随便找个 json 解析工具一提取就搞定了,只是稍微费一点功夫而已。
    3. 我们作为软件的用户,要区分软件的「内部实现」和「外部接口」的边界。简单地说,思源如何组织笔记文件、如何存储笔记数据,这个是软件的内部实现,本来就是会随软件发展不断变化的。但思源将笔记「按目录和文本文件组织为本地磁盘的数据」,这是软件给用户和开发者的保证,可以预期是不会急剧变化的,可以理解为是一种外部接口。我们搭建自己的工作流,要基于软件的「外部接口」而非「内部实现」。如果真要基于「内部实现」,就要做好持续跟随改变的准备,而不是不断给软件开发者提要求说「内部实现」变化不合理。
    4. 期望思源笔记尽快梳理出一个稳定的开发接口,包括数据格式、数据存储、查询修改等,在能给出稳定预期的地方,尽量给出稳定预期,这样大家知道什么会变,什么不变,搭建工作流和开发额外工具也就比较放心。
  • audiolabj 2 2 赞同

    深以为然!

    1. 文件名的纠结,我们实践里的理解是:习惯于一段内容在一个可见的文件里,然后以文件名看更新,以文件或文件夹移动或复制内容,习惯这样的话,文件名不用改成 ID,随便改动一些都会不好找;如果是以内容块来组织的话,移动,查找和复制都是块的内容(包括块的嵌套),习惯了这样,焦点就在内容里,而且是每个组织好的要点里(在 RemNote 里是一个 Rem),这对于知识的组织管理而言,是更顺畅的。文档名,只是应用内一个大容器块的标签管理,,如果需要文件级的交换,用导出 md 后的 pandoc 类的方法,转成 ppt 也行。
    2. 修改历史管理,我们也是用 git 来做的,而且是团队协作,十几个成员,从需求到设计到开发代码到测试,直到交付和销售支持材料,甚至开发者自己的学习笔记,都用思源做源头内容管理,3 个月时间我们用思源已经发布了两个产品都在 B 端客户进入部署阶段。git 管理协同,相对于飞书和语雀的在线历史管理,优势不仅在于可以管理到每个 commit 的每个要点,而且在于文档的发布范围,可以多分支管理,小组的 feature 开发的需求文档,和主版本分离,没啥问题。
    3. 思源的 json 格式,是我们团队选择思源并且每人购买会员的理由,不仅 ID 和标签的对应可以管理,而且节点间的关系,完全可以还原;如果改了数据库作为主存,反倒会引起我们很大担心,且不说如何用范式化 schema 适应 nosql 的定义场景,字段映射的管理,元数据和实际内容的对应查看,引用完整性的潜在风险这些坑,光是实时分享版本改动引起的数据字段结构和值域定义更新问题,就成了一个麻烦。
    4. 还是那句话,思源笔记作为知识管理工具,而不是编辑排版工具的方向,非常认同;知识图谱的 schema,就是图;比起范式化的二维表,protege 这类知识定义 rdf 工具,是和 json 这种格式具有好得多的亲和力的,而且思源支持的 graphviz,可以直接和 protege 进行转换。
    5. 同样,也是期望思源尽快梳理出稳定的开发接口,sql 查询的数据库元数据和字典文档开放程度能更好一些,便于跟进;如果有一天,思源把主存储改为封闭数据库,不再坚持“本地 + 文本格式”,也希望及时告知,恕不能够继续一路升级同行了。
    6. 思源用户圈子建立很难得,大家场景不同,需求各异,求同存异不容易,一方面让开发者协调取舍,一方面多交流,理解,分享一些不改版本条件下解决问题的方法吧。

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...
    1. 其实比较认同作者的观点的,每次大版本更新,我也是提心吊胆。最近几次的版本的改动还是挺大的,1.2.5 我第一次迁移就直接把数据丢失了,幸好有备份,通过回到老版本还原数据再重新安装才搞定。之前还在工作群里推荐过思源,后来主动说明思源的不稳定性问题,避免别人上车结果把人坑了。不是忠实粉丝,是经不起这样折腾的。
    2. 文件名 ID 的最大问题,除了资源管理器外,第三方同步盘的同步日志就直接无法看了。我平时公司和家两台电脑,每天都需要使用到同步功能,原先就打开同步盘看下最新同步的文件名,现在基本上实现不了这点了。思源的同步功能尝试过,中间爆出来好多次连不到服务器,直接弃用了。
    3. 关于子文档,到底有啥好处?什么场景下有用?这方面在更新说明中完全没有体现,说实在话,我现在都不知道子文档的用处是啥?有大佬能指导一下嘛。
    1 回复
  • 其他回帖
  • WeiCJ 1 赞同

    我想你应该只是想要能直接看到 md 文件,从而在必要的时候可以直接分享 md 文件,😂 我感觉这个与子文档并不冲突。我看了思源笔记在之前的版本也是用 md 文件存储,然后启动的时候转为数据库,以便于检索;后面版本改为 sy 的 json 文件,依旧是数据库检索;现在是改了文件的展示形式,但依旧是数据库检索。

    综上所述,目前只是文件的展示形式变了,造成部分人的观感下降了 😋 那软件可以在数据根目录建一个 md 文件夹,里面存放自动生成的 md 文件即可。(其实也就相当于自动导出功能,这样也许可以平衡不同使用习惯的人)

    1 回复
  • 88250 4 10 赞同 2 评论

    你好,是时候和大家分享一些这方面我们的设计考虑了。

    从使用角度

    思源不是文本编辑器,而是知识管理系统。如果以编辑器的方式来使用,肯定会感到别扭的。

    • 同一层级下需要支持同名文档,这样能将新建、重命名、移动等操作的同名阻断问题降低,使用起来更流畅
    • 子文档形式比文件夹形式效率更高,能够充分利用文档树的空间,从概念上也统一为文档,减少不必要的实体
    • 分享和协作不是思源现阶段的目标,现在就这样用的话是肯定不会好用的,协作大概在 v3 阶段会开始设计

    从技术实现角度

    优先考虑稳定性。

    • 通过文件实现易变数据的互操作性是一个糟糕和错误的方向,因为多个进程各自直接读写易变文件有概率会导致数据损坏。概括一点讲就是试图通过共享文件、共享内存来实现互操作性的方案都存在一致性问题,正确的方案是通过 API 进行交互,各进程内自己保证一致性
    • 使用人类可读的文本在跨系统平台时存在大小写问题,比如 Linux 上允许同时存在 SiYuansiyuan 文件,但是 Windows 上则不允许,该情况一旦发生数据就可能会被损坏

    寻求平衡

    我们一直在寻求对普通用户和对社区开发者都友好的平衡点。

    • 对普通用户尽量屏蔽底层细节,所以思源迟早要覆盖一些在文件系统上的常规操作,比如批量移动、删除文档,最终目标是用户不必关心文件结构,专注于使用
    • 对开发者而言,需要的是稳定的方案,如果某个方案可能存在某个问题,那么这个问题一定会在将来的某个时候发生

    忒修斯之船

    思源这样一直更新下去,还是当初的思源吗?

    在发布 v1.2.0 的时候我们说过,如果没有更好的替代方案,不会轻易删除已有特性,这次变更我们觉得并没有违背这个承诺。

    一个产品如果没有明确的产品方向和架构思路,这个产品就算做到能用也不会是个好产品。至于个性鲜明或者说思路清奇的产品能否被用户接受,这只能用市场来检验了。好产品无需推广,烂产品就算被骂死也不会有所改变。

    最后,我们作为主创团队,直接劝退用户的话不太礼貌,然后还会有人说:“你看他们,傲慢得不得了,容不得半点意见”。但这样的评价并不重要,重要的是我们觉得浪费了大家的时间精力,与其忍着用,不如早点换。

    以上。

    @participants

    5 回复
    我觉得对于大部分人来说,这次更新都是很好用的,所以 D 大不要担心啦
    haojiao
    我觉得很好用的啦
    haojiao
  • fangly 1 赞同

    我认为,目前文档名 id 化带来的唯一负面影响就是在坚果云中看不到是什么文件修改了(至于无法在资源管理器中管理文件,等到 d 大把思源内部的文件树功能优化好,资源管理器就完全用不到了,文件树完全可以替代资源管理器。至于想要把思源源文件分享给别人,肯定是在思源内部查看,编辑好,然后文件树中打开-打开文件位置,不可能有人从 C 盘根目录一步一步打开文件夹找文件吧,显然是思源内部定位后再定位源文件更快)

    因此,用户真实的需求是能查看到文件修改的历史记录,用户默认的查看方法是通过坚果云查看,现在通过坚果云查看不了了,用户就觉得 id 化这个决定是不好的。

    所以用户抱怨的根本不是文档名 id 化,而是无法查看文件修改的历史记录

    然而事实上,要查看文件修改的历史记录最好的方法是通过坚果云吗?这种依赖第三方软件的方法肯定是无法作为最佳解决方案的。我认为更好的解决方案是 d 大开发查看文件历史修改记录的功能。

    因此大家不应该反对文档 id 化,这是没有意义的,而应该让 d 大开发查看文件历史修改记录的功能。

    1 操作
    fangly 在 2021-08-22 18:56:11 更新了该回帖
  • 查看全部回帖

推荐标签 标签

  • JavaScript

    JavaScript 一种动态类型、弱类型、基于原型的直译式脚本语言,内置支持类型。它的解释器被称为 JavaScript 引擎,为浏览器的一部分,广泛用于客户端的脚本语言,最早是在 HTML 网页上使用,用来给 HTML 网页增加动态功能。

    730 引用 • 1281 回帖 • 2 关注
  • Bootstrap

    Bootstrap 是 Twitter 推出的一个用于前端开发的开源工具包。它由 Twitter 的设计师 Mark Otto 和 Jacob Thornton 合作开发,是一个 CSS / HTML 框架。

    18 引用 • 33 回帖 • 648 关注
  • JSON

    JSON (JavaScript Object Notation)是一种轻量级的数据交换格式。易于人类阅读和编写。同时也易于机器解析和生成。

    52 引用 • 190 回帖 • 1 关注
  • React

    React 是 Facebook 开源的一个用于构建 UI 的 JavaScript 库。

    192 引用 • 291 回帖 • 370 关注
  • 知乎

    知乎是网络问答社区,连接各行各业的用户。用户分享着彼此的知识、经验和见解,为中文互联网源源不断地提供多种多样的信息。

    10 引用 • 66 回帖 • 1 关注
  • abitmean

    有点意思就行了

    31 关注
  • Outlook
    1 引用 • 5 回帖 • 5 关注
  • 星云链

    星云链是一个开源公链,业内简单的将其称为区块链上的谷歌。其实它不仅仅是区块链搜索引擎,一个公链的所有功能,它基本都有,比如你可以用它来开发部署你的去中心化的 APP,你可以在上面编写智能合约,发送交易等等。3 分钟快速接入星云链 (NAS) 测试网

    3 引用 • 16 回帖
  • Pipe

    Pipe 是一款小而美的开源博客平台。Pipe 有着非常活跃的社区,可将文章作为帖子推送到社区,来自社区的回帖将作为博客评论进行联动(具体细节请浏览 B3log 构思 - 分布式社区网络)。

    这是一种全新的网络社区体验,让热爱记录和分享的你不再感到孤单!

    134 引用 • 1127 回帖 • 110 关注
  • 浅吟主题

    Jeffrey Chen 制作的思源笔记主题,项目仓库:https://github.com/TCOTC/Whisper

    1 引用 • 28 回帖
  • WebClipper

    Web Clipper 是一款浏览器剪藏扩展,它可以帮助你把网页内容剪藏到本地。

    3 引用 • 9 回帖 • 1 关注
  • 书籍

    宋真宗赵恒曾经说过:“书中自有黄金屋,书中自有颜如玉。”

    80 引用 • 396 回帖
  • 创造

    你创造的作品可能会帮助到很多人,如果是开源项目的话就更赞了!

    186 引用 • 1020 回帖
  • Logseq

    Logseq 是一个隐私优先、开源的知识库工具。

    Logseq is a joyful, open-source outliner that works on top of local plain-text Markdown and Org-mode files. Use it to write, organize and share your thoughts, keep your to-do list, and build your own digital garden.

    7 引用 • 69 回帖 • 5 关注
  • CSDN

    CSDN (Chinese Software Developer Network) 创立于 1999 年,是中国的 IT 社区和服务平台,为中国的软件开发者和 IT 从业者提供知识传播、职业发展、软件开发等全生命周期服务,满足他们在职业发展中学习及共享知识和信息、建立职业发展社交圈、通过软件开发实现技术商业化等刚性需求。

    14 引用 • 155 回帖
  • Google

    Google(Google Inc.,NASDAQ:GOOG)是一家美国上市公司(公有股份公司),于 1998 年 9 月 7 日以私有股份公司的形式创立,设计并管理一个互联网搜索引擎。Google 公司的总部称作“Googleplex”,它位于加利福尼亚山景城。Google 目前被公认为是全球规模最大的搜索引擎,它提供了简单易用的免费服务。不作恶(Don't be evil)是谷歌公司的一项非正式的公司口号。

    49 引用 • 192 回帖
  • LeetCode

    LeetCode(力扣)是一个全球极客挚爱的高质量技术成长平台,想要学习和提升专业能力从这里开始,充足技术干货等你来啃,轻松拿下 Dream Offer!

    209 引用 • 72 回帖 • 3 关注
  • 持续集成

    持续集成(Continuous Integration)是一种软件开发实践,即团队开发成员经常集成他们的工作,通过每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。

    15 引用 • 7 回帖
  • FreeMarker

    FreeMarker 是一款好用且功能强大的 Java 模版引擎。

    23 引用 • 20 回帖 • 464 关注
  • 微服务

    微服务架构是一种架构模式,它提倡将单一应用划分成一组小的服务。服务之间互相协调,互相配合,为用户提供最终价值。每个服务运行在独立的进程中。服务于服务之间才用轻量级的通信机制互相沟通。每个服务都围绕着具体业务构建,能够被独立的部署。

    96 引用 • 155 回帖
  • 深度学习

    深度学习(Deep Learning)是机器学习的分支,是一种试图使用包含复杂结构或由多重非线性变换构成的多个处理层对数据进行高层抽象的算法。

    43 引用 • 44 回帖 • 1 关注
  • RemNote
    2 引用 • 16 回帖 • 19 关注
  • Linux

    Linux 是一套免费使用和自由传播的类 Unix 操作系统,是一个基于 POSIX 和 Unix 的多用户、多任务、支持多线程和多 CPU 的操作系统。它能运行主要的 Unix 工具软件、应用程序和网络协议,并支持 32 位和 64 位硬件。Linux 继承了 Unix 以网络为核心的设计思想,是一个性能稳定的多用户网络操作系统。

    954 引用 • 944 回帖
  • HBase

    HBase 是一个分布式的、面向列的开源数据库,该技术来源于 Fay Chang 所撰写的 Google 论文 “Bigtable:一个结构化数据的分布式存储系统”。就像 Bigtable 利用了 Google 文件系统所提供的分布式数据存储一样,HBase 在 Hadoop 之上提供了类似于 Bigtable 的能力。

    17 引用 • 6 回帖 • 67 关注
  • 外包

    有空闲时间是接外包好呢还是学习好呢?

    26 引用 • 233 回帖 • 1 关注
  • CAP

    CAP 指的是在一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可兼得。

    12 引用 • 5 回帖 • 636 关注
  • Sublime

    Sublime Text 是一款可以用来写代码、写文章的文本编辑器。支持代码高亮、自动完成,还支持通过插件进行扩展。

    10 引用 • 5 回帖