扩展 LotusScript 的能力

需求

LotusScript 最近的更新是版本 7/8 时增加的 WebService 调用者、提供者,这已经是快十年前的事情了。现在 LotusScript 已经明显落后,欠缺的大量基础能力:JSON 解析器、跨代理的数据缓存、HTTP Client、完善的面向对象机制、将函数作为参数传递……这严重制约了应用层面的开发。

IBM 对此问题的应对是推出 XPages,一种新的开发模式。XPages 确实是一个不错的东西,展现和数据分离、內置 Ajax 框架……但是,作为应用开发商我们无法抛弃历史资产一切推倒重来。所以 XPages 我们只能用来做一些新的业务、功能点,对于原有的业务还是要继续在 LotusScript 上发展。

所以我们必须自己来扩展 LotusScript 的能力。

方案

LotusScript 类、函数库

首先想到的就是直接用 LotusScript 来实现,但这只能解决一部分问题:比如 JSON 解析器。而类似于 HTTP Client 这种,LotusScript 就无能为力了。

我们也确实做了一版 LotusScript 的 JSON 解析器,但是性能实在是太差了:由于需要一个字符一个字符的解析,最终导致一个 15K 的 JSON 串解析出来要花 0.5 秒。结果我们又废弃了它,重新回到手工拆解字符串的老路上。

此路不通。

LSX(LotusScript eXtension)

这是最正统的扩展 LotusScript 的方式(看看名字就知道),实际上我们使用的 NotesDocument 等 Domino 后台对象都是用这种方式扩展出来的。实际的 C 代码编译成共享库,位于 nlsxbe.dll(n=windows平台前缀,lsx,be=Back-end)中,LotusScript 引擎会自动加载它,所以我们不用再通过 USELSX lsxbe 来手工加载。

LSX 的优点有很多:跨平台、与 LotusScript 无缝集成……

但是,LSX 现在已经处于一个半废弃的状态。为什么这么说呢,LSX 最新版 8.0 于 2009 年发布,再往前一版就是 1999 年了。所以即使是最新版也缺少了很多内容:xlinux 64 位的支持等。

此路不通。

LS2C(LotusScript to C API)

这是一个比较成熟、使用较多的方案。一般都用于在 LotusScript 中调用底层的 C API(例如隐藏设计、重新编译所有代码),因为这些 API 没有暴露到 LotusScript 这一层。

LS2C 与 LSX 相比会多一些限制,比如:

  • 只能传递数值、字符串等基础类型,无法传递 NotesDocuemnt
  • 不支持 LotusScript 扩展语法(doc.itemName 这种)

但这个方案至少在持续的更新,而且 C 这个层面不需要使用 Lotus 的开发工具包,用任何编译器生成标准的共享库即可。

我们最终采用了此方案。

经验总结

变长字符串

C 语言中不支持变长字符串,所以我们在返回变长字符串时,实际返回的是一个 handle 值;这个 handle 值再通过另一个 API 获取实际的字符串(类似于 NSFDbOpen 返回的 handle)。

handle 用完之后要注意释放(类似于 NSFDbClose)。

中文的处理

LS2C 的字符串参数传递有三种声明方式:

  1. arg As String
    采用操作系统本地的编码方式,windows 一般为 GBK,linux 一般为 UTF-8。不同系统编码不同,不利于统一处理
  2. arg As LMBCS String
    不管操作系统本地的编码方式,统一采用 LMBCS。这种编码方式适用范围太小,仅 Lotus 自己的产品线
  3. arg As Unicode String
    不管操作系统本地的编码方式,统一采用 UTF-16。推荐使用此方式,对环境的适应性更好。
    但要注意 UTF-16 英文也用双字节存储,C 语言中会把其中的 0x00 识别为字符串结束。所以进入到 C 代码内部后,可以转为 UTF-8 存储。
    还要注意不同硬件下字节序的问题,x64 和 Power 架构下刚好是相反的。

Double 类型的传递

LS2C 在 64 位环境下的参数传递有 bug,浮点数无法正常处理。

bug 已经提交给 IBM 处理(更新:已确认不修复),在解决前可以先把参数改为按引用传递(即使是只读的参数,也不按值传递)。

资源的释放

有一部分内存在 C 代码中分配后,后续会被 LotusScript 端继续使用。所以需要在 LotusScript 端不再使用的时候,手工释放这部分资源。

推荐的做法是把这类资源包装成 LotusScript Class,在 Delete 析构函数中释放资源。这样相当于 LotusScript 引擎会帮忙自动跟踪变量的引用,比较方便。

调试共享库加载失败

Domino 给出的错误信息很模糊:“dll 加载失败”,没有太多有用的信息。而错误背后可能的原因有很多:文件找不到、32/64 位不匹配、缺少依赖的库……

可以先通过其他语言(比如 LuaJIT)调用共享库,会得到更详细的错误信息。成功之后再放到 Domino 环境下调试。

共享库的权限

Linux、Aix 环境下要注意上传的 so 库必须要有运行权限。

共享库的更新

Linux、Aix 环境下 so 库更新的行为有些奇怪,有时候覆盖 so 文件后会导致 Domino 崩溃。看上去像是内存中保留了一部分旧版的代码,与新版搭配在一起就不行了。

所以更新共享库时要停掉Domino。

总结

虽然 LotusScript 已经步入晚年,但我们希望通过 LS2C 这种方式给它注入新的活力,在既有业务资产中继续发光发热。

3 评论

  1. 总结里的第一句满是伤感。大佬厂商们都忙着做“大事”了,cloud\ai\bigdata,传统应用难以打动他们动用大笔投资来做这些事情。

    1. 其实对厂商来说,加个JSON解析器是举手之劳,可惜就是不做。
      发展新的开发框架可以理解,老的修修补补我觉得也是很有必要的。
      还好Domino10引入了HTTP Client?是个好迹象