2016 Unicode Conference拾遗（七）

上回说到作为数据收集端的client在整个cloud based GVT架构中需要完成的事务，本文我将和大家一起来继续解读server端的SSGT-API的功能。

·        接收client端的请求同时加载globalized数据（包括支持的语言列表、locales、消息ID, 默认消息, 默认的buffer大小和期望的buffer大小等）。

·        基于从client端收集来的数据执行GVT。不同的GVT API之间相互独立，以实现高内聚低耦合。

·        API G11n逻辑检查

·        验证信息编码（字符集）

·        测试消息截断

·        分析测试结果

·        提供GVT结果报告

 

关于SSGT-API的结构及流程图如下。

初步设计的测试API包括以下三类:

•G11N 逻辑分析测试

•Charset setting测试

•Truncation验证

为了调用这些测试API，G11n Repository会向其提供所有必要的g11n测试数据，包括支持的语言列表，缺省的locale参数，message ID，缺省的buffer大小，还有所有需要被测试G11n API顺序列表。

 

而Server端整体SAAS流程图如下所示。

作者提供了三段测试示例，分别是G11n的逻辑分析测试，charsetsetting测试以及潜在的truncationverification。

 

说道truncation预判，个人认为用GVT用buffer size来检测也许不是一个最优的办法，日后的文章中我会陆续提到针对该问题，笔者所在的组内目前所使用和推广的一种更直接，更行之有效的解决方案。

 

最后作者总结了整个cloud based GVT架构的优势，例如跟所有SAAS一样，该设计定义了pay as you go的服务理念和方法；支持在云端GVT的API；省去consultant onsite support的费用已达到节约整体成本的目的；使G11n更适应敏捷模型；测试前移，早期即可检测任何潜在的G11n问题（例如可译性和文化支持等）。在我看还有一句话作者没有明示，即所有希望实现G11n as a Service的同学，这套架构基本上就可以作为你们的设计蓝图+范本啦。O(∩_∩)O