登录 注册

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

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

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

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

    26030 引用 • 108019 回帖 • 1 关注
3 引用
建议用回文件名的功能 1.2.5 文件 (夹) 名称 ID 化，是否与本地化的初衷渐行渐远？ • dwe3030
升级 1.2.8 后，文档树没加载出来 • 88250
新版思源笔记用了 sy 格式，怎样不使用这个功能？ • 88250
保定 位置
2 关注
5 收藏
3 赞同
3 引用
44 回帖
9
3
2
2
6.0k 893 329 1.5k 101 77 1 3.0k

相关帖子

优质回帖
  • 88250 • • 4 • 10 赞同
    订阅者 MOD

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

    从使用角度

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

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

    从技术实现角度

    优先考虑稳定性。

    • 通过文件实现易变数据的互操作性是一个糟糕和错误的方向，因为多个进程各自直接读写易变文件有概率会导致数据损坏。概括一点讲就是试图通过共享文件、共享内存来实现互操作性的方案都存在一致性问题，正确的方案是通过 API 进行交互，各进程内自己保证一致性
    • 使用人类可读的文本在跨系统平台时存在大小写问题，比如 Linux 上允许同时存在 SiYuan 和 siyuan 文件，但是 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. 思源用户圈子建立很难得，大家场景不同，需求各异，求同存异不容易，一方面让开发者协调取舍，一方面多交流，理解，分享一些不改版本条件下解决问题的方法吧。
44 回帖
1.2.5 文件 (夹) 名称 ID 化，是否与本地化的初衷渐行渐远？

欢迎来到这里！

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

注册 关于
请输入回帖内容 ...
  • boboxing •
    订阅者 支持者 勇士 作者
    • 作为发帖人，本人只是深度笔记用户，不是程序员兼职笔记用户
    • 外部接口，内部实现的范式感觉也基本适用于 VSCode 了，VSCode 用 ID 存文件，程序员们是否欣然接受，毕竟可以重命名了。
  • 其他回帖
  • fgdl30458df • • 1 评论

    不觉得文件 ID 化有什么好处和"文件重名"有什么优势和值得的需求

    要说好处的话也只是对于开发者而言的吧,但对于用户体验来讲确实被大砍了一刀.

    正如上方反馈,面对全是 Id 数字的文件确实让很多"深度使用"需求的场景变得非常不方便,甚至变得无法实现.

    这等于思源将自己"长处"主动变成了短处.

    当然作为开发者可以无视这些反馈,因为些意见都是思源问题的存在.

    对于普通用户来讲一款笔记软件的消费粘性其实对他们没有那么大,面对"如雨春笋"的笔记软件的出现他们有很多的选择,

    但对于"深度用户"来讲为了实现"特殊"需求的使用场景,他们往往不惜进行消费,而这些用户群体才是思源应该把握住的,这样用户群体也是思源能够继续走下去的动力.

    所以将文件 ID 化我觉得开发者应该要更加的慎重考虑了,毕竟一款笔记的成功不应该只看功能自身,而是看和其他平台的"互动兼容性"强不强,

    毕竟没有什么笔记软件是完美的存在,和其他软件的互动性可以保证自身的缺陷,在一定程度上得到弥补,或者干脆将第三方变成自身通往成功的"轮子".

    2 回复
    同感 + 同意， 为了实现某些特性，缓解某些问题，文件名 ID 化应该是最容易实现的方案，编程的易实现性放在了用户体验之上。
    boboxing • • 1 赞同
  • 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. 思源用户圈子建立很难得，大家场景不同，需求各异，求同存异不容易，一方面让开发者协调取舍，一方面多交流，理解，分享一些不改版本条件下解决问题的方法吧。
  • larryggao • • 1 赞同
    订阅者 付费者 支持者
    1. 其实比较认同作者的观点的，每次大版本更新，我也是提心吊胆。最近几次的版本的改动还是挺大的，1.2.5 我第一次迁移就直接把数据丢失了，幸好有备份，通过回到老版本还原数据再重新安装才搞定。之前还在工作群里推荐过思源，后来主动说明思源的不稳定性问题，避免别人上车结果把人坑了。不是忠实粉丝，是经不起这样折腾的。
    2. 文件名 ID 的最大问题，除了资源管理器外，第三方同步盘的同步日志就直接无法看了。我平时公司和家两台电脑，每天都需要使用到同步功能，原先就打开同步盘看下最新同步的文件名，现在基本上实现不了这点了。思源的同步功能尝试过，中间爆出来好多次连不到服务器，直接弃用了。
    3. 关于子文档，到底有啥好处？什么场景下有用？这方面在更新说明中完全没有体现，说实在话，我现在都不知道子文档的用处是啥？有大佬能指导一下嘛。
    1 回复
  • 查看全部回帖
boboxing
保定
回帖
26
 帖子
10
 积分
13342

近期热议

推荐标签 标签

  • B3log

    B3log 是一个开源组织，名字来源于“Bulletin Board Blog”缩写，目标是将独立博客与论坛结合，形成一种新的网络社区体验，详细请看 B3log 构思。目前 B3log 已经开源了多款产品：Sym、Solo、Vditor 和 思源笔记。

    1063 引用 • 3455 回帖 • 149 关注
  • TensorFlow

    TensorFlow 是一个采用数据流图（data flow graphs），用于数值计算的开源软件库。节点（Nodes）在图中表示数学操作，图中的线（edges）则表示在节点间相互联系的多维数据数组，即张量（tensor）。

    20 引用 • 19 回帖
  • Facebook

    Facebook 是一个联系朋友的社交工具。大家可以通过它和朋友、同事、同学以及周围的人保持互动交流，分享无限上传的图片，发布链接和视频，更可以增进对朋友的了解。

    4 引用 • 15 回帖 • 450 关注
  • MySQL

    MySQL 是一个关系型数据库管理系统，由瑞典 MySQL AB 公司开发，目前属于 Oracle 公司。MySQL 是最流行的关系型数据库管理系统之一。

    693 引用 • 537 回帖
  • Mac

    Mac 是苹果公司自 1984 年起以“Macintosh”开始开发的个人消费型计算机，如：iMac、Mac mini、Macbook Air、Macbook Pro、Macbook、Mac Pro 等计算机。

    167 引用 • 597 回帖
  • MyBatis

    MyBatis 本是 Apache 软件基金会 的一个开源项目 iBatis，2010 年这个项目由 Apache 软件基金会迁移到了 google code，并且改名为 MyBatis ，2013 年 11 月再次迁移到了 GitHub。

    173 引用 • 414 回帖 • 363 关注
  • BAE

    百度应用引擎（Baidu App Engine）提供了 PHP、Java、Python 的执行环境，以及云存储、消息服务、云数据库等全面的云服务。它可以让开发者实现自动地部署和管理应用，并且提供动态扩容和负载均衡的运行环境，让开发者不用考虑高成本的运维工作，只需专注于业务逻辑，大大降低了开发者学习和迁移的成本。

    19 引用 • 75 回帖 • 677 关注
  • MongoDB

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

    91 引用 • 59 回帖 • 4 关注
  • 安装

    你若安好，便是晴天。

    132 引用 • 1184 回帖 • 1 关注
  • Spring

    Spring 是一个开源框架，是于 2003 年兴起的一个轻量级的 Java 开发框架，由 Rod Johnson 在其著作《Expert One-On-One J2EE Development and Design》中阐述的部分理念和原型衍生而来。它是为了解决企业应用开发的复杂性而创建的。框架的主要优势之一就是其分层架构，分层架构允许使用者选择使用哪一个组件，同时为 JavaEE 应用程序开发提供集成的框架。

    947 引用 • 1460 回帖 • 2 关注
  • 架构

    我们平时所说的“架构”主要是指软件架构，这是有关软件整体结构与组件的抽象描述，用于指导软件系统各个方面的设计。另外还有“业务架构”、“网络架构”、“硬件架构”等细分领域。

    142 引用 • 442 回帖
  • SendCloud

    SendCloud 由搜狐武汉研发中心孵化的项目，是致力于为开发者提供高质量的触发邮件服务的云端邮件发送平台，为开发者提供便利的 API 接口来调用服务，让邮件准确迅速到达用户收件箱并获得强大的追踪数据。

    2 引用 • 8 回帖 • 503 关注
  • JRebel

    JRebel 是一款 Java 虚拟机插件，它使得 Java 程序员能在不进行重部署的情况下，即时看到代码的改变对一个应用程序带来的影响。

    26 引用 • 78 回帖 • 675 关注
  • H2

    H2 是一个开源的嵌入式数据库引擎，采用 Java 语言编写，不受平台的限制，同时 H2 提供了一个十分方便的 web 控制台用于操作和管理数据库内容。H2 还提供兼容模式，可以兼容一些主流的数据库，因此采用 H2 作为开发期的数据库非常方便。

    11 引用 • 54 回帖 • 672 关注
  • Love2D

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

    14 引用 • 53 回帖 • 559 关注
  • LeetCode

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

    209 引用 • 72 回帖 • 1 关注
  • Solidity

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

    3 引用 • 18 回帖 • 438 关注
  • 快应用

    快应用 是基于手机硬件平台的新型应用形态；标准是由主流手机厂商组成的快应用联盟联合制定；快应用标准的诞生将在研发接口、能力接入、开发者服务等层面建设标准平台；以平台化的生态模式对个人开发者和企业开发者全品类开放。

    15 引用 • 127 回帖 • 4 关注
  • 星云链

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

    3 引用 • 16 回帖 • 1 关注
  • 服务器

    服务器，也称伺服器，是提供计算服务的设备。由于服务器需要响应服务请求，并进行处理，因此一般来说服务器应具备承担服务并且保障服务的能力。

    125 引用 • 585 回帖 • 1 关注
  • RESTful

    一种软件架构设计风格而不是标准，提供了一组设计原则和约束条件，主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制。

    30 引用 • 114 回帖 • 1 关注
  • DevOps

    DevOps（Development 和 Operations 的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

    59 引用 • 25 回帖
  • Tomcat

    Tomcat 最早是由 Sun Microsystems 开发的一个 Servlet 容器，在 1999 年被捐献给 ASF（Apache Software Foundation），隶属于 Jakarta 项目，现在已经独立为一个顶级项目。Tomcat 主要实现了 JavaEE 中的 Servlet、JSP 规范，同时也提供 HTTP 服务，是市场上非常流行的 Java Web 容器。

    162 引用 • 529 回帖 • 5 关注
  • WordPress

    WordPress 是一个使用 PHP 语言开发的博客平台，用户可以在支持 PHP 和 MySQL 数据库的服务器上架设自己的博客。也可以把 WordPress 当作一个内容管理系统（CMS）来使用。WordPress 是一个免费的开源项目，在 GNU 通用公共许可证（GPLv2）下授权发布。

    45 引用 • 114 回帖 • 172 关注
  • Anytype
    3 引用 • 31 回帖 • 25 关注
  • Swift

    Swift 是苹果于 2014 年 WWDC（苹果开发者大会）发布的开发语言，可与 Objective-C 共同运行于 Mac OS 和 iOS 平台，用于搭建基于苹果平台的应用程序。

    34 引用 • 37 回帖 • 555 关注
  • GitHub

    GitHub 于 2008 年上线，目前，除了 Git 代码仓库托管及基本的 Web 管理界面以外，还提供了订阅、讨论组、文本渲染、在线文件编辑器、协作图谱（报表）、代码片段分享（Gist）等功能。正因为这些功能所提供的便利，又经过长期的积累，GitHub 的用户活跃度很高，在开源世界里享有深远的声望，并形成了社交化编程文化（Social Coding）。

    209 引用 • 2040 回帖 • 1 关注

最新标签