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

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

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

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

    22019 引用 • 87804 回帖 • 2 关注

相关帖子

优质回帖
  • 88250 4 10 赞同

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

    从使用角度

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

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

    从技术实现角度

    优先考虑稳定性。

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

    寻求平衡

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

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

    忒修斯之船

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

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

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

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

    以上。

    @participants

  • programfan 2 3 赞同

    说几点看法和期望:

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

欢迎来到这里!

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

注册 关于
请输入回帖内容 ...
  • WeiCJ 1 赞同

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

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

    1 回复
  • 文件名保留,数据库该怎样就怎样,这不是最佳实现吗?是 json 或 md 无所谓,仅仅只文件名的可读性而已。轻度用户可能体会不到重度用户此时的痛苦。重度用户本来数量也不多。😂

  • Achuan-2 1 赞同

    首先还是能定位文件的,所以你前面将资源管理器变成管理空气略显夸张。定位之后,如果需要分享,照样可以复制分享。或者直接导出 md 文件分享。

    image.png

    其次也打开 sy 文件也可以确定下文件名的

    image.png

    文件存储 ID 化应该不仅仅为了子文档才这样做的,因为用中文名照样可以实现。

    具体为何要 ID 化,我不好乱说,还是等官方来解释吧。

    如果 ID 化能更好保护隐私、能让思源的功能实现更加稳定,那我愿意支持 ID 化。

    并且这种 ID 化,于我来说,在分享层面应该不会有特别大的影响,依旧是通过思源定位文件位置,然后分享,如果愿意接受、习惯这些 id,应该不会对分享造成太大的麻烦才对。

    反而我觉得是管理文档层面不大方便,例如我需要将几个文档移到另外一个笔记本下,可能就需要反复查看 id,移动的时候因为思源会锁文件又需要关闭思源,就会非常麻烦。不过这点等官方支持跨笔记本移动文档,和批量拖动移动文档后会得到解决

    3 回复
    1 操作
    Achuan-2 在 2021-08-22 10:58:38 更新了该回帖
  • boboxing 1 评论

    定位是能定位,以前的事还是能做,还可以把文件名和 ID 放到个 excel 表里,岂不查着更方便,毕竟只有几百个文件夹,几千个文件而已 😭 。资源管理器进行文件级别的管理是不依赖其他任何软件的,只有打开某个特定文件双击即可,思源是所有软件里唯一的例外(所以对于思源,资源管理器近乎管理空气,它不能脱离思源使用了,必须反复多次回查),而思源又是目前是使用最高频的笔记软件....

    如果需要展示所有 ID 和文件名,可以用模板实现
    Achuan-2
  • ID 化给我最大的好处就是同级文档它能重名了……

    1 回复
  • boboxing 5 评论

    恰恰也是分享层面,现在一看同步列表(坚果云提供),别人分享我的都变成了一串 ID,完全不知道分享的啥。当然分享时我是把思源当 word 用了,而且用的很舒服。试想,现在互相分享,别人传给你的是一串 ID,发给别人的也是一串 ID,这不是观感的问题,是工作效率问题了。这里的分享不是到处分享,而是源文件分享,坚果可以方便的设置读和写的权限,所以分享根本不用导出。直接分就完了,还能利用那些精美的主题。现在导出都是没有主题的。

    如果需要分享,为何不用其他协作软件呢。思源我觉得更倾向个人知识管理
    Achuan-2
    因为 1.2.5 以前大大小小几十个版本都可以这么做啊.......
    boboxing
    我只是想说,子文档啥的有其他实现方法,ID 化是对用户习惯最大入侵的方法....
    boboxing
    个人和分享不矛盾啊。word 也算个人软件吧。如果他只提供 ID 文件名存储方式呢。哎,好吧,是我把思源本就小众的笔记软件用得更加小众了。
    boboxing
    @boboxing office 的软件也算个人软件吗??而且你应该把思源和 OneNote 对比,而不是 word。我其实前面说了,ID 化有其他的考量,肯定不会只为了子文档就大费周章改架构的
    Achuan-2
  • 这.....,文档重名???是同级目录下可以重名吧?这是什么应用场景?需要再同级目录下搞俩重名的笔记文件?

    1 回复
  • 有啊,没法重名之前我一堆相同名字后面跟不同数字的笔记……也算是我的习惯问题了

    1 回复
  • 有点吃惊 😳 ,同目录下相同的名字,还是一堆,能举个例子么?都有啥一样的名字。

    1 回复
  • leiyuy

    用 1.2.31 的时候,我个人感觉思源笔记的存储方式和 calibre 的管理思路是一样的,不仅能在线管理,还能在本地管理。calibre 是文件 + 数据库存贮。

    这个管理思路我是比较喜欢的。

    既能数据库化存储,为将来构建知识图谱奠定基础,同样也能够兼顾得到本地资源管理器,为实际的文件管理无缝融合。

  • 图一个省事儿……之前是一堆 灵感 1 灵感 2 灵感 11111 什么的东西

  • leiyuy

    1.2.31 的文件名存贮不能够避免文件名重复引发的数据丢失问题,这可能是思源优化的一个出发点。

    1 回复
  • boboxing 1 赞同

    文件名就不应该重复啊。谁也不会把自己的俩孩子起相同的名字吧。

    2 回复
  • Hildaquan

    我自己有近千个文档,我有时引用的时候也会偶尔发现有重名的。当自己的笔记数非常多的时候,重名是不可避免的。

    一般我发现重名后,要么合并文档,要么根据内容异同改名

    1 回复
  • 本来就不在意文档名的内容,但是放进一起就方便用 SQL 查路径,现在一堆 新文档,然后查上层的文档目录就很好用

  • 支持!支持子文档!

    1 回复
  • 不是很理解,子文档有什么特别的优势或者便利吗?

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

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

    从使用角度

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

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

    从技术实现角度

    优先考虑稳定性。

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

    寻求平衡

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

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

    忒修斯之船

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

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

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

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

    以上。

    @participants

    5 回复
    我觉得对于大部分人来说,这次更新都是很好用的,所以 D 大不要担心啦
    haojiao
    我觉得很好用的啦
    haojiao
  • 这个回复比较清晰了,00E11C6B.png

  • 感谢主创耐心回复!

    • ID 化的主因是“使用人类可读的文本在跨系统平台时存在大小写问题,比如 Linux 上允许同时存在 SiYuansiyuan 文件,但是 Windows 上则不允许,该情况一旦发生数据就可能会被损坏”,我一直以为是子文档的原因。但 ID 化不是“更好的替代方案"
    • 子文档是个好特性
    • 关于软件的一切,主创拥有唯一最终解释权
  • 这里的重名特指同级目录下的文件重名。

  • 支持并理解 D 大的部分想法,但并不完全认同,子文档是挺精致的,也好看,但是没有配套的措施出来前,无法凸显出它的好处(如何更好的利用好原来的文件夹)。

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

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

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

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

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

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

  • 我觉得新版挺好用。思源可以批量导出 md 文档,根本不影响分享啊,从资源管理器按文件夹分享才麻烦,伴随的图片附件挑选起来多麻烦啊。

    其实,现在对一些人来说就缺了个笔记本之间的移动文档功能,否则应该不需要资源管理器了,这个功能估计很快会有。

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

    之前其他用户解释,大概意思就是: 子文档主要就是让文档树更多的集中有用的信息. 因为文件夹只是一个区分的作用,本身没有什么其他作用.变成子文档之后,文档书内都是文件,大概意思就是没有多余的东西了,同时文档之间的逻辑性更强了.

    1 回复
  • fangly 1 赞同

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

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

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

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

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

    1 操作
    fangly 在 2021-08-22 18:56:11 更新了该回帖
  • fgdl30458df 1 评论

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

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

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

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

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

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

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

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

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

    2 回复
    同感 + 同意, 为了实现某些特性,缓解某些问题,文件名 ID 化应该是最容易实现的方案,编程的易实现性放在了用户体验之上。
    boboxing 1 赞同
  • programfan 2 3 赞同

    说几点看法和期望:

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

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

    举个例子?我真没看出来哪个功能在文档名 id 化后无法实现

    有什么功能需求就说需求,别把所有问题都怪到文档名 id 化上

    1 回复
  • fgdl30458df 1 赞同

    我们是用户不是开发者 OK? 是体验使用和消费者.

    不方便这一点就足够说明问题了,

    我们只需要反馈,和等待最终的结果,来决定是否继续支持这款笔记软件

    至于我说的"无法实现",你非要将问题隐隐提上到技术层面来讲,那么还真是有非常多方法可以"实现"的

    但是有必要吗? 作为用户我只需要"使用"和消费,难道我需要自己写个工具吗?

    至于提出需求, 我们是可以提出需求,但最终实现是未知的,可能并不是自己想要的,也可能被忽略,这都是有可能的

    1 回复
    1 操作
    fgdl30458df 在 2021-08-22 20:42:08 更新了该回帖
  • fangly 1 赞同

    我什么时候把问题隐隐提到技术上了?可能我的表述让你产生了误解,我就是从用户角度来说的。

    除了坚果云看不了更新日志之外没有任何功能因为 id 化而受到实质影响,然而坚果云看更新日志这本身就不属于思源的功能。

    你说思源哪个功能需求现在因为 id 化而不方便?

    1 回复
  • fgdl30458df

    工作繁忙,不跟你扯了,这无意义,就算是我"一叶障目"吧,

    至于思源,看之后的版本吧.

  • 我就是对比来看的,我只是觉得子文档很适合我而且比文件夹有优势。这点不冲突。ID 化的话确实比较麻烦,有好有坏吧,做不了评价 Thanks♪(・ω・)ノ

  • 好用点赞!

  • 如果真的不能接受,直接用旧的版本也不是不行安装包也都在。失去的无非就是集市和同步,也不影响用 👀

  • 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. 思源用户圈子建立很难得,大家场景不同,需求各异,求同存异不容易,一方面让开发者协调取舍,一方面多交流,理解,分享一些不改版本条件下解决问题的方法吧。
  • 感谢,看了你对子文档的回复后,稍微对这个功能有点理解了。

    这方面感觉官方做的不是很好,每次更新,都没有示例来说明新功能的作用、用法,完全靠用户自己瞎琢磨。

    另外看了上面的“优质回帖”后,估计都是程序员背景,一些在程序员看起来非常容易的事情(比例搭个 git 这种),在非程序员的体验中是非常复杂的。思源如果只是做一款面向程序员的笔记软件,那也无可厚非。但是如果未来想走向“小白”类普通用户,还任重而道远!!!

    1 回复
  • 是的,我也是这样认为, siyuan 对计算机以外的行业人员来说上手难度真的很大.

    由于是 D 和 V 两个人开发,各种功能和进度都有些忙不过来了.具体示例只能靠社区的大家用爱发电了.

    而且他们两的收入来源并不靠这个软件,所以未来很长一段时间内,这方面都不会有太大的改善.

  • json 文件挺好的

  • buzzingbee 1

    虽然我也是第一次用这种设计的笔记软件,但我还是感觉用 id 作为文档名和块名,是目前最正确的方向。只有 id 才具有可管理性,而文件名,路径等等肯定不行。因为只有 id 才具有唯一性,不管文档标题变化不变化,或者移动了位置, id 都能保持不变,这是追塑文档必须要解决的基础问题。

    作为用户,我觉得文档或文件夹 id 化应该是用户可以接受的选择。不然,很多功能估计不好实现,最后的产品可能更难用。将块与文档,文档与文件夹打通,是简化数据结构,降低程序复杂度,从而最终创建功能更强的软件的基础。人的创造力(智力)是有限的,一个简单但不平凡的基础,应该是通向更高层复杂度而不导致混乱的方法保证。

    我喜欢笔记软件本地化的原因主要是它不依赖网络,它不需要因网络延迟而等待,同时它还具有许多网络编辑器不易实现的文档间切换特性。

    选择思源,那就放心让思源去管吧,我相信这是正确的道路。

    @88250

  • dwe3030

    同意

  • @programfan @audiolabj JSON 格式我们可能会做一些调整,请关注 Issue #8712 · siyuan-note/siyuan

    1 回复
  • audiolabj 1 赞同 1 评论

    看到这个调整计划了,感谢 D 大还在考虑兼容 git 场景的用户,会注意关注,相关变更烦请继续告知,谢谢!

    v2.9.5 已经增加这个选项了(设置 - 文档树 - 使用单行保存),新用户默认会开启,老用户默认不开启。
    88250
请输入回帖内容 ...

推荐标签 标签

  • 单点登录

    单点登录(Single Sign On)是目前比较流行的企业业务整合的解决方案之一。SSO 的定义是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。

    9 引用 • 25 回帖
  • SOHO

    为成为自由职业者在家办公而努力吧!

    7 引用 • 55 回帖 • 18 关注
  • Elasticsearch

    Elasticsearch 是一个基于 Lucene 的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎,基于 RESTful 接口。Elasticsearch 是用 Java 开发的,并作为 Apache 许可条款下的开放源码发布,是当前流行的企业级搜索引擎。设计用于云计算中,能够达到实时搜索,稳定,可靠,快速,安装使用方便。

    117 引用 • 99 回帖 • 223 关注
  • Linux

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

    939 引用 • 940 回帖
  • PostgreSQL

    PostgreSQL 是一款功能强大的企业级数据库系统,在 BSD 开源许可证下发布。

    22 引用 • 22 回帖 • 1 关注
  • 酷鸟浏览器

    安全 · 稳定 · 快速
    为跨境从业人员提供专业的跨境浏览器

    3 引用 • 59 回帖 • 31 关注
  • golang

    Go 语言是 Google 推出的一种全新的编程语言,可以在不损失应用程序性能的情况下降低代码的复杂性。谷歌首席软件工程师罗布派克(Rob Pike)说:我们之所以开发 Go,是因为过去 10 多年间软件开发的难度令人沮丧。Go 是谷歌 2009 发布的第二款编程语言。

    497 引用 • 1387 回帖 • 294 关注
  • SQLServer

    SQL Server 是由 [微软] 开发和推广的关系数据库管理系统(DBMS),它最初是由 微软、Sybase 和 Ashton-Tate 三家公司共同开发的,并于 1988 年推出了第一个 OS/2 版本。

    19 引用 • 31 回帖
  • Git

    Git 是 Linux Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

    209 引用 • 358 回帖
  • 小说

    小说是以刻画人物形象为中心,通过完整的故事情节和环境描写来反映社会生活的文学体裁。

    28 引用 • 108 回帖
  • WiFiDog

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

    1 引用 • 7 回帖 • 586 关注
  • 宕机

    宕机,多指一些网站、游戏、网络应用等服务器一种区别于正常运行的状态,也叫“Down 机”、“当机”或“死机”。宕机状态不仅仅是指服务器“挂掉了”、“死机了”状态,也包括服务器假死、停用、关闭等一些原因而导致出现的不能够正常运行的状态。

    13 引用 • 82 回帖 • 53 关注
  • Mobi.css

    Mobi.css is a lightweight, flexible CSS framework that focus on mobile.

    1 引用 • 6 回帖 • 733 关注
  • 服务器

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

    124 引用 • 580 回帖
  • 旅游

    希望你我能在旅途中找到人生的下一站。

    90 引用 • 899 回帖
  • OkHttp

    OkHttp 是一款 HTTP & HTTP/2 客户端库,专为 Android 和 Java 应用打造。

    16 引用 • 6 回帖 • 60 关注
  • BAE

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

    19 引用 • 75 回帖 • 632 关注
  • GitBook

    GitBook 使您的团队可以轻松编写和维护高质量的文档。 分享知识,提高团队的工作效率,让用户满意。

    3 引用 • 8 回帖 • 2 关注
  • 代码片段

    代码片段分为 CSS 与 JS 两种代码,添加在 [设置 - 外观 - 代码片段] 中,这些代码会在思源笔记加载时自动执行,用于改善笔记的样式或功能。

    用户在该标签下分享代码片段时需在帖子标题前添加 [css] [js] 用于区分代码片段类型。

    54 引用 • 292 回帖
  • 思源笔记

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

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

    22019 引用 • 87804 回帖 • 2 关注
  • JVM

    JVM(Java Virtual Machine)Java 虚拟机是一个微型操作系统,有自己的硬件构架体系,还有相应的指令系统。能够识别 Java 独特的 .class 文件(字节码),能够将这些文件中的信息读取出来,使得 Java 程序只需要生成 Java 虚拟机上的字节码后就能在不同操作系统平台上进行运行。

    180 引用 • 120 回帖 • 1 关注
  • 创业

    你比 99% 的人都优秀么?

    84 引用 • 1399 回帖 • 1 关注
  • Flume

    Flume 是一套分布式的、可靠的,可用于有效地收集、聚合和搬运大量日志数据的服务架构。

    9 引用 • 6 回帖 • 621 关注
  • RabbitMQ

    RabbitMQ 是一个开源的 AMQP 实现,服务器端用 Erlang 语言编写,支持多种语言客户端,如:Python、Ruby、.NET、Java、C、PHP、ActionScript 等。用于在分布式系统中存储转发消息,在易用性、扩展性、高可用性等方面表现不俗。

    49 引用 • 60 回帖 • 366 关注
  • OnlyOffice
    4 引用 • 2 关注
  • Netty

    Netty 是一个基于 NIO 的客户端-服务器编程框架,使用 Netty 可以让你快速、简单地开发出一个可维护、高性能的网络应用,例如实现了某种协议的客户、服务端应用。

    49 引用 • 33 回帖 • 19 关注
  • 反馈

    Communication channel for makers and users.

    123 引用 • 911 回帖 • 237 关注