云表格的技术（三）

完整的云表格产品必然是跨终端的，可以有网页版，桌面版，移动版。对于桌面版/移动版，离线支持是一个基本的功能。另一方面，云表格是基于OperationalTransformation的技术，该技术是依赖于后台权威的串行化处理的。由此，会出现一个问题，即新建数据的ID问题。

新建的数据，无论是新建的工作表，或者是新建的一行，一列，都会有ID。这个ID是会存储到后台服务器中的权威数据，并且一般情况下，该ID是后台服务器生成的。

但是，在离线的情况下，桌面端/移动端是可以创建工作表或者新建一行一列的，这时，我们无法从后台服务器生成ID。换句话讲，client端是需要有生成ID的能力的。

在大多数情况下，我们可以选择String作为ID的存储类型，并且通过各种技术都可以生成保证唯一性的ID.但是，基于String的ID是不利于做ordering或者increment的。使用String做ID的话，client端在离线时生成ID的问题就非常简单，且client端生成的ID是可以直接应用到 数据库的。但是，使用例如Int类型来做ID的话，问题就复杂了。

对于这种复杂的情况，首先，我们要明确的是，只有后台是权威的生成ID的来源，而client端生成ID,是local ID。其次，我们需要认识到，在client端和server端，必然有两套ID。client端的ID会发到后台得到ACK,附带后台生成的权威ID.为了保存处理两套ID的对应关系，需要在client端引入一个映射关系表，在client端与server端通信时，通过映射关系做一层转译。

这种方式也有局限性，他完全依赖于一发一收的握手机制，即对于local ID，向server端发送求得ACK之前，是不能提前发送接下去的操作消息的。因为求得ACK，才能填充映射关系表，而在映射关系表不能给出local ID和serverID的对应关系前，任何client与server的通信是无法转译的。恰好，在基础Operational Transformation的实现中，也是依赖于一发一收机制的，所以，目前看来，使用该种机制是practical的做法。