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

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

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

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

    25933 引用 • 107489 回帖

相关帖子

优质回帖
  • 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. 思源用户圈子建立很难得,大家场景不同,需求各异,求同存异不容易,一方面让开发者协调取舍,一方面多交流,理解,分享一些不改版本条件下解决问题的方法吧。

欢迎来到这里!

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

注册 关于
请输入回帖内容 ...
  • dwe3030

    同意

  • 其他回帖
  • 88250 4 10 赞同 2 评论

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

    从使用角度

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

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

    从技术实现角度

    优先考虑稳定性。

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

    寻求平衡

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

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

    忒修斯之船

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

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

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

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

    以上。

    @participants

    5 回复
    我觉得对于大部分人来说,这次更新都是很好用的,所以 D 大不要担心啦
    haojiao
    我觉得很好用的啦
    haojiao
  • 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. 思源用户圈子建立很难得,大家场景不同,需求各异,求同存异不容易,一方面让开发者协调取舍,一方面多交流,理解,分享一些不改版本条件下解决问题的方法吧。
  • 支持并理解 D 大的部分想法,但并不完全认同,子文档是挺精致的,也好看,但是没有配套的措施出来前,无法凸显出它的好处(如何更好的利用好原来的文件夹)。

    当然,因为每个人的工作流不同,所以肯定会误伤部分用户,所以其实重大更新前可以来个预告。

    支持知识主帖作者认为的思源逐渐丧失了本地资源管理的功能的观点,因为在某个版本把 asset 文件统一合并的时候,我就体会到了,包括现在,打开本地文件夹,打开的全是一堆 id 化的文件,很难轻易区分哪个是哪个了。
    那这样会不会有大的影响呢?个人认为,要想用户接受,思源需要做到的是,不断提升稳定性和对附件管理的更友好地支持,以及便利好用的导出功能。这样我不管理文件夹其实无所谓。

    那么,似乎 1.2 后,思源的确不太有丢图片的情况了(这也是我当初不支持 asset 文件统一的原因,因为丢图了在当前文件夹,我还能找到并补救)

    另外,附件,我觉得目前而言,思源的附件管理并不很方便,可能我倾向的是为知笔记那种管理方式。

    最后,导出的话,应该也是一致需要努力的方向,因为很多问题容易反复。

    总之,希望思源越来越好,也希望大家保持沟通,不要轻易离开或指责,大家一起为更好的知识管理而努力!

  • 查看全部回帖

推荐标签 标签

  • 游戏

    沉迷游戏伤身,强撸灰飞烟灭。

    185 引用 • 825 回帖
  • WiFiDog

    WiFiDog 是一套开源的无线热点认证管理工具,主要功能包括:位置相关的内容递送;用户认证和授权;集中式网络监控。

    1 引用 • 7 回帖 • 612 关注
  • Vditor

    Vditor 是一款浏览器端的 Markdown 编辑器,支持所见即所得、即时渲染(类似 Typora)和分屏预览模式。它使用 TypeScript 实现,支持原生 JavaScript、Vue、React 和 Angular。

    371 引用 • 1856 回帖 • 1 关注
  • Ant-Design

    Ant Design 是服务于企业级产品的设计体系,基于确定和自然的设计价值观上的模块化解决方案,让设计者和开发者专注于更好的用户体验。

    17 引用 • 23 回帖 • 2 关注
  • MongoDB

    MongoDB(来自于英文单词“Humongous”,中文含义为“庞大”)是一个基于分布式文件存储的数据库,由 C++ 语言编写。旨在为应用提供可扩展的高性能数据存储解决方案。MongoDB 是一个介于关系数据库和非关系数据库之间的产品,是非关系数据库当中功能最丰富,最像关系数据库的。它支持的数据结构非常松散,是类似 JSON 的 BSON 格式,因此可以存储比较复杂的数据类型。

    91 引用 • 59 回帖 • 5 关注
  • JWT

    JWT(JSON Web Token)是一种用于双方之间传递信息的简洁的、安全的表述性声明规范。JWT 作为一个开放的标准(RFC 7519),定义了一种简洁的,自包含的方法用于通信双方之间以 JSON 的形式安全的传递信息。

    20 引用 • 15 回帖 • 25 关注
  • LaTeX

    LaTeX(音译“拉泰赫”)是一种基于 ΤΕΧ 的排版系统,由美国计算机学家莱斯利·兰伯特(Leslie Lamport)在 20 世纪 80 年代初期开发,利用这种格式,即使使用者没有排版和程序设计的知识也可以充分发挥由 TeX 所提供的强大功能,能在几天,甚至几小时内生成很多具有书籍质量的印刷品。对于生成复杂表格和数学公式,这一点表现得尤为突出。因此它非常适用于生成高印刷质量的科技和数学类文档。

    12 引用 • 59 回帖 • 4 关注
  • Gzip

    gzip (GNU zip)是 GNU 自由软件的文件压缩程序。我们在 Linux 中经常会用到后缀为 .gz 的文件,它们就是 Gzip 格式的。现今已经成为互联网上使用非常普遍的一种数据压缩格式,或者说一种文件格式。

    9 引用 • 12 回帖 • 175 关注
  • Bootstrap

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

    18 引用 • 33 回帖 • 651 关注
  • 心情

    心是产生任何想法的源泉,心本体会陷入到对自己本体不能理解的状态中,因为心能产生任何想法,不能分出对错,不能分出自己。

    59 引用 • 369 回帖
  • Solidity

    Solidity 是一种智能合约高级语言,运行在 [以太坊] 虚拟机(EVM)之上。它的语法接近于 JavaScript,是一种面向对象的语言。

    3 引用 • 18 回帖 • 435 关注
  • Visio
    1 引用 • 2 回帖 • 2 关注
  • uTools

    uTools 是一个极简、插件化、跨平台的现代桌面软件。通过自由选配丰富的插件,打造你得心应手的工具集合。

    7 引用 • 27 回帖
  • Angular

    AngularAngularJS 的新版本。

    26 引用 • 66 回帖 • 561 关注
  • 职场

    找到自己的位置,萌新烦恼少。

    127 引用 • 1708 回帖
  • Love2D

    Love2D 是一个开源的, 跨平台的 2D 游戏引擎。使用纯 Lua 脚本来进行游戏开发。目前支持的平台有 Windows, Mac OS X, Linux, Android 和 iOS。

    14 引用 • 53 回帖 • 558 关注
  • 开源

    Open Source, Open Mind, Open Sight, Open Future!

    412 引用 • 3588 回帖
  • Telegram

    Telegram 是一个非盈利性、基于云端的即时消息服务。它提供了支持各大操作系统平台的开源的客户端,也提供了很多强大的 APIs 给开发者创建自己的客户端和机器人。

    5 引用 • 35 回帖
  • 小薇

    小薇是一个用 Java 写的 QQ 聊天机器人 Web 服务,可以用于社群互动。

    由于 Smart QQ 从 2019 年 1 月 1 日起停止服务,所以该项目也已经停止维护了!

    35 引用 • 468 回帖 • 762 关注
  • 微信

    腾讯公司 2011 年 1 月 21 日推出的一款手机通讯软件。用户可以通过摇一摇、搜索号码、扫描二维码等添加好友和关注公众平台,同时可以将自己看到的精彩内容分享到微信朋友圈。

    133 引用 • 796 回帖
  • 友情链接

    确认过眼神后的灵魂连接,站在链在!

    24 引用 • 373 回帖
  • SQLite

    SQLite 是一个进程内的库,实现了自给自足的、无服务器的、零配置的、事务性的 SQL 数据库引擎。SQLite 是全世界使用最为广泛的数据库引擎。

    4 引用 • 7 回帖 • 6 关注
  • OnlyOffice
    4 引用 • 23 关注
  • 阿里巴巴

    阿里巴巴网络技术有限公司(简称:阿里巴巴集团)是以曾担任英语教师的马云为首的 18 人,于 1999 年在中国杭州创立,他们相信互联网能够创造公平的竞争环境,让小企业通过创新与科技扩展业务,并在参与国内或全球市场竞争时处于更有利的位置。

    43 引用 • 221 回帖 • 58 关注
  • BND

    BND(Baidu Netdisk Downloader)是一款图形界面的百度网盘不限速下载器,支持 Windows、Linux 和 Mac,详细介绍请看这里

    107 引用 • 1281 回帖 • 36 关注
  • 深度学习

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

    43 引用 • 44 回帖 • 2 关注
  • Anytype
    3 引用 • 31 回帖 • 24 关注