2020年5月22日开发社群应用重要讨论记录备忘录。
-
2020年5月22日开发社群应用重要讨论记录备忘录。
今天讨论的人员有：昌用CID:CY_vpAvpisa 一棵树上 村长 一棵树上 facjas 大师
刘教授向pisa_n5oN发起讨论：freedrive的“追加”操作的问题，考虑得如何？感觉跟“更新”混合在一个drive_id系列里面，确实有问题。追加是同一类的系列数据，更新是同一个数据的不同版本。放在一起会造成混乱。追加应该是通过系列tx来完成。比如，某cid的通话记录，由该cid作为输入，在metadata里定义数据类型为“通话记录”，data里保存本次通话记录。下次通话后，cid再次发送存储交易，只记录上次存储之后的新内容即可。该cid的所有通话记录，可以根据区块高度或时间戳组合起来，这样就不用在现有协议里增加“追加”操作了。逻辑上应该也比较清楚了。
pisa 提问：追加应该是通过系列tx来完成。 这个是指 独立于drive_id 操作？
刘教授回答：是的，drive_id里面是不同版本，这样可以区分开追加和更新了。区块链本身包含了时序上的追加的逻辑。这样是不是清晰些？通话记录可以只追加。已经存储的不需要更新。有的应用的数据即需要追加，又需要更新。在一个drive_id里面就很难实现了。追加采取独立drive_id就可以解决了。不同drive_id数据可以通过cid和metadata里的类型、编号或版本来建立关联。
pisa回答：这里操作的对象应该还是 drive_id 标识的主体吧。
更新和追加操作。分开作为不同的操作，是会更清晰些。
更新里面定义了： 当某个字段的长度字段是 ‘0x00' 表示不更新；当长度字段是‘0x01’,且内容字段是'0x00' ，表示清除这个字段所有内容。注意更新操作都是覆盖以前的内容。
所以需要额外一个追加操作，而且具体的协议主体，基本和更新差不多。其次实现层面也没有问题，create , update ,append. 增加一个append操作就可以吧，这个操作正对某些字段。 具体查看分析内容的时候，组合 create, update, append的内容即是完整内容。 这样其实都是基于drive_id作为标识。对外使用来说负担小。都以drive_id作为基础。
刘教授解释：如果一个drive_id，先有了数据A1，然后追加了数据A2，接下来一个更新操作，那么这个更新是针对A1的更新，还是针对A2的更新？不同drive_id就没问题了。CID创建一个drive_id1，写入数据A1，第二天再创建一个drive_id2，写入数据A2。更新A1在drive_id1中更新，更新A2在drive_id2中更新。按照时间顺序和cid、类型和编号。drive_id1和drive_id2，具有相同的数据结构，并且有时序，可以组合为一个系列数据。每个数据可以更新、删除，这样操作应该就完备了。
pisa回答：因为所有操作都是时序的，只需要把所有时序操作按先后顺序累积起来，这里只是累积的规则多了一个 追加的规则。我感觉跨drive_id 来操作一个数据，会让整个事情没有边界。因为你不知道哪些drive_id 的操作应该作用到一个数据上。而都是以drive_id定位的话，就没没这个问题，这也是当时抽象出drive_id 的目的。跨业务衔接的时候，也是drive_id.实现层面，单drive_id的操作，好像更简单。这种情况，就需要额外规定，我们哪些drive_id 是操作这份数据的。 然后分别解析这些drive_id的操作，合起来，分别解析这些操作累积出完整的数据。本质都是要额外一个操作：
1， 跨drive_id， 就是要额外规定哪些drive_id操作 这份数据
2，单drive_id, 就是额外规定一个动作，操作这个数据。程序形式化容易度来说， 单drive_id上 增加一个额外的append操作更好实现。这一系列操作都是 时序的，是以交易形式体现在freedrive里的，只需要把这些操作按时间顺序串联在一起就可以，这里有2个情况： 追加已有字段的数据，追加新字段的数据。这个没有问题的，可以为追加分别说明即可。
刘教授继续发起讨论：这个不是时序的问题。更新是时序问题，按照后面的为准。但追加是两个不同的数据。你试试具体处理上面那个问题。
pisa提出问题：不知道我理解对不对，昌用老师担心的是，追加新字段 的情况？
刘教授回复：不是追加字段，是追加独立的完整数据项。
pisa询问：完整的数据项， 就是独立的业务？
刘教授回复：一个数据项包括多个字段。更新的话是对一个数据项的个别字段更新。
pisa继续询问：如果是独立的业务，那就应该按你说的，独立的drive_id，然后规定一个 append操作， 同时也具有update能力。
刘教授回答：我的意思是一项贡献是一个drive_id，可以update。update对这个贡献里的某些字段进行修改，不用append了直接创建一个新的drive_id，通讯记录也是这样的。昨天通话记录一个drive_id。
pisa回答：上述问题都已经清楚和理解。
刘教授继续回复：那就不需要append操作了，否则会乱。
pisa询问：可以，如果 update 和 追加操作 会交叉 呢？
刘教授回复：新增字段，仍然是update，追加就是一个新的drive_idupdate在已有的drive_id里要么是新的，要么是改旧的。两种情况不会交叉。
pisa回复：如果不交叉，就是你说的新drive_id.
刘教授回复：是的。否则就会有交叉，就很麻烦新的drive_id就不会交叉了。
pisa询问：不交叉的话，其实新drive_id, 还是现在的规则是吧。
刘教授回复：freedrive是非常重要底层基础设施，逻辑尽量简洁。对的，还是现在的规则，只是明确了应用层的处理方式。
pisa回答：是的，好，这也样会清晰些。
一棵树上询问：签名泄露有什么影响？
刘教授回复：看签名的内容是什么了，签名本身是给人验证的你发一笔交易，签名就泄露一次。
刘教授向facjas发起讨论：你那边实现cid签名登录的规范是什么，能否给@一棵树上 讲一下。他在18cash上实现。当然，最好是形成一个协议，发布出来，打开开发app的时候自愿选择。采用较多的话，对大家和生态都有好处。既能实现跨平台共识，实现规模效应，又能重复开发设计。
facjas回复：马上发出来：
Dplanet登录协议，签名字数据：
1字节平台代号 + 1字节平台操作码 + 6字节平台用户ID + 2字节随机数
密签对上述字符串签名，发送过来就行了，
例如：
D1100234z9
平台代号: D
操作码(登录)：1
平台用户ID:100234
随机数：z9
刘教授向facjas 提出：所以，刚做好的时候，顺手写成协议，是最好的。
大师询问：兄弟们，freedrive的接口有了吗。
pisa回复大师：可以先看看接口文档，看看对比下 自己的业务 流程是咋样的？
https://github.com/fchwallet/freedriveJ
大师回复：已经收到。
pisa发起讨论：这几天为设计这个解析实现来回变化了好几次。
metadata和data 里面什么内容，freedrive 不关心了。都由应用层根据协议来解析。
先前实现方案，freedrive 也去解析metadata, data, 总要协调两端是否解析正确，导致调试起来也很麻烦。
大师个人观点：个人觉得，metadata，你是要校验格式的，格式定义越规范，将来解析的时候可能就少很多麻烦，然后扩展的部分，建议放到一个ext的结构中，主体是严格规范的，但是扩展部分可以宽松，甚至自定义，这也是众多协议的处理方式。
pisa回复大师：freedrive的定位是？你考虑下，我认为他是一个分布式存储，让用户经过不同应用来协同操作自己在freedrive上的数据。如果freedrive去解析协议或者部分解析，比如metadata，看似让后面的获取会方便，但是这让freedrive和具体的协议也就是应用耦合在一起了。这样的耦合本身技术上没问题，但是让freedrive限制了协议或者应用，这也让维护协调成本过高。这样freedrive和协议以及应用只共用了一个lockingscript, metadata, data这样一个框架。而不共享框架里面的内容。不同协议就是不同的metadata, 这会让freedrive的更新频次制约上层应用和协议的进展。这很不利。
大师回复：如果这样理解的话，我觉得完全可以不用开发就能完成我们的分布式存储，现在开源的分布式对象存储引擎很多，完全可以拿过来直接使用，而且更成熟更稳定更可靠。
李国荣提出个人观点：先弄解耦的，以后还有耦合的机会。反过来，以后再想解耦就得全部推到重来了。
上述谈论的问题大家一直认为，那个快或者是马上能够展现出了的就先搞那个。