这是一篇作者 Geoffrey Litt 10个月前写的，很快被自己本人遗忘的文章，但它确是一个有趣的话题。
Bring Your Own Client = BYOC，可以自由的选择你喜欢的应用程序来与一些数据进行交互。
例如，我可以使用 Sublam Text 编程，而我的队友使用 vim
我们不需要为了在我们之间选择一个编辑器而战斗到死。
有几十个文本编辑器可供选择，而且没有专有文件格式的锁定。
把这种情况和使用 Google Docs 的情况相比，为了实现相互间的协作，我们都需要使用相同的编辑器。
在云应用中，实时协作逻辑通常与一个特定的编辑器相连接，
即使 Google 想要公开一个用于在第三方编辑器中编辑 Google Docs 的 API 也是非常具有挑战性的。
使用文本编辑器和 git 的情况更好，因为编辑与协作逻辑是分离的。
只需要就版本控制解决方案达成一致，让该解决方案公开了一个简单的 AP，使许多编辑器可以与之交互即可。
但公平地说，本地和云并不是唯一的影响因素。
即使在本地软件中，协作者也常常被迫集中在一个专有客户端(Microsoft Office，Adobe 套件)中。
反而云服务是可以通过正确的 API 以及支持的第三方客户端生态系统来推进协作者。
然而，云应用程序加剧了一些问题。
对于本地文件，内置了一些默认的开放性，即便遇到是专有的文件格式也可以进行逆向工程。
对于云应用程序，默认情况下只有一个官方客户端，除非该服务主动公开一个 API 。
似乎本地优先软件是可以更广泛地推广 BYOC 。
如果有一个用于 Google Docs 风格的文字处理的蓬勃发展的第三方客户端生态系统，
所有这些客户端都可以相互操作，甚至支持实时协作，那会是什么样子？
01具体的例子
围绕开放标准建立的客户生态系统的一些现有成功范例:
- text editors / IDE
- RSS readers
- email clients
- web browsers
我想要 BYOC 的地方:
- Google Slides
- Figma
- Notion
- Trello / Asana / shared todo lists
- repl.it
- Google Docs
- 我希望我可以在我喜欢的本地编辑器中编写这个文档，但是也支持内联评论和实时协作。
- 有没有可能建立一个 VSCode 扩展来实时编辑 GoogleDocs？
02更细颗粒度的思考
今天，我们一般认为 BYOC 在“apps”的维度，但是我们能够更细粒度地选择单独的 UI 元素吗？
我是否可以不需要选择单个电子邮件客户端，
而是从收件箱、撰写邮件的窗口和垃圾邮件过滤器中构建我喜欢的电子邮件客户端？
03需要解决的问题
- Schema 兼容性
- 所有编辑器是否需要就一个严格指定的格式达成一致？
- 如果格式之间存在可调和的差异，我们是否可以构建“实时转换器”，在每次更改时在它们之间进行转换？
- 本质上，想象一下 Pages 和 Word 之间的协作，在任何 app 的每一次按键上都运行一个双向导出的文件
- 这个问题与单个编辑器中的模式版本控制问题密切相关，但是 BYOC 会使事情变得更加复杂。
- 保存编辑意图
- git + 文本编辑器的解耦有一个缺点: 文本格式无法捕捉编辑的意图，所以 git 不能很好地处理合并冲突。
- 这是使编辑与协作脱钩的根本原因吗？
- 或者有什么方法可以设计出更好地保存意图的 API，同时也支持开放的客户端生态系统？
- 决定如何在 CRDT 中存储数据似乎是这里的关键问题?
- 特定于编辑器的附加元数据
- 有些编辑器需要存储不属于“核心数据模型”的附加数据
- Sublime Text stores my .sublime-workspace
- 如何在不污染其他编辑器正在使用的数据的情况下顺利工作？
- 代码分发
- 传统的代码分发是通过集中的方式进行的，但是代码是否可以与文档一起以分散的方式分发呢？
- 如果在一个文档中协作，可以直接分享一个我正在使用的编辑器，而不需要给你发送 Github 链接？
- 这可能是过于复杂的事情
- 这个想法的灵感来自 https://webstrates.net/
- 创新
- 不幸的是，稳定的开放格式会限制产品创新
- 例如，电子邮件客户端受到遵守电子邮件标准的束缚。我们能减轻这种影响吗？
- 我认为浏览器这个例子已经在进步和开放之间找到了一个很好的平衡点。
04后记
这篇内容在 Hacker News 上意外产生了热烈讨论
Q：标准不会让创新变得更加困难吗？
A：是的，这是一个很大的挑战。例如，email 和 IRC 落后于 Slack 和 Reddit，因为它们很难改变标准。我认为关键在于追求更加灵活和可扩展的标准: 一个有用的80% 的兼容性，而不是一个完美的100% 。一旦放弃了一个精确的标准，就很容易累积成吨的复杂性。(我认为语义 Web 努力解决这个问题，试图提供模式灵活性。)因此，我们还需要更好的工具，让开发人员和用户都能轻松理解部分兼容性。参见 Project Cambria
Q：80% 的兼容性听起来像是一团糟? Word 和 OpenOffice 不能很好地互操作。
A：我认为，有了正确的基础技术来帮助开发人员构建最大限度兼容的格式，我们就可以避免不正确的格式转换所带来的最糟糕的问题。但是，这确实留下了一个实质性的设计问题: 即使一切都正常工作，当两个软件不完全兼容时，你会向用户展示什么？如何告诉用户，对于使用不同应用程序的协作者，他们的操作可能会显示不同的结果？关于这些问题，我需要想很多。
Q ：云的商业模式根深蒂固，如果没有政府的干预，这种情况真的会发生吗？
A：商业激励是一个重大挑战。也许某种形式的政府干预可以有所帮助，但是最终它将与逆风作斗争，除非用户和开发人员对这种变化感到兴奋。对于典型的用户和典型的开发人员，我认为最可持续发展的方式是使 BYOC 成为最方便的选择。在 Desktop 上，开发人员可以方便地使用用户现有的文件系统。在 Web 上，没有用户控制的文件系统，所以通常最简单的方法就是将数据放到数据库中，然后添加一张票到待办事项列表中，以便有朝一日构建一个面向公众的 API。如果我们有一个方便的用户控制的存放数据的地方，那么这种情况会发生什么变化呢？参见 Ink & Switch 的本地优先软件文章，了解一些关于新数据架构如何使用户和开发人员都可以轻松实现正确的事情的想法。
05现有技术
- Webstrates，，可以在不同应用程序中操作的“多态”工具。例如，可以在任何应用程序中使用的颜色选择器。
- SOLID ，“apps become views”
- Google Wave 一个实时协作的平台，有一个丰富的开放扩展 API，但它太复杂了，最终失败了。
- Braid 正在探索扩展 HTTP 的方法，以支持跨不同客户端的协同编辑。
06后记
Geoffrey Litt 正在麻省理工攻读博士学位，研究这个课题。前方有很多挑战和未解决的问题，但对如何取得进展有一些想法。并感到兴奋的是，有一些聪明的方法可以逐步将我们从现状推向 BYOC 的世界，而不是重新创造一切。
原文