呼叫处理语言的构架与必要条件( 七 )


第二个缺点,对于能完整表示的语言来说,它们能让脚本自动,分析,但却相当的麻烦.正如每一个分析工具都有自己的翻译语言.因此,可以从文档编写世界里得到一个规律:假如文档的组成语言象HTML或者XML一样,并且可以被熟练的人员轻松编写,强有力的文档编程语言,象LaTeX或者Postscript通常是用不到的.当然,现在有字处理系统可以以LaTeX格式保存文档,但决不能接受任意写入的LaTeX文档,不管原文档的格式,构架.相比较而言,任何一个HTML编辑者都可以通过网络来编写HTML文档,其中高质量的一些还可以在编辑其他文档的同时保留它们的格式.
11相关工作
11.1在服务创建环境中
国际电信联盟,对服务创建环境[8]作了抽象的描述.所描述的服务都是在传统的交换电话网络中进行的,就象一个非循环图中的能够涉及到的行为和决定.许多网络服务的主顾,使用更改过的或是升级过的版本,为了它们所有者的服务创建环境.
11.2SIPCGI(详解网关接口)
网关借口[9]是SIP服务器操作服务的接口.跟CPL不同,它是一个非常低级的接口.因此对于那些并不可信的用户所写的服务并不能合适的运行.
第十页上讲的"网络电话服务编程"(ProgrammingInternetTelephonyServices)具体的讨论了SIPCGI与CPL的相似与不同之处.
12必要的语言特征
这部分列举了呼叫处理语言的几种工具,我们相信它们对于执行命令是必要的.并且与所描述的构架相符.
12.1语言特征
这里列举了一些抽象的特性,是所有被提议的呼叫处理语言都应该具有的.
@体积小,效率高,易执行
为什么这点是必须的呢?作为对这个问题答案的补充,网络服务器应该能够处理体积巨大的呼叫,但我们不希望CPL的执行成为一个大瓶颈.达到这个目的的有效方法之一,就是在执行之前先编译它.
@轻易实现
对于一个在服务器上运行的脚本,不合理的构造就会导致用户不能到达,或者使运行时期的错误显示变的困难(尽管双信道的机制可以缓解这个问题,就象电子邮件一样).因此,它应该是易于检验的,当脚本连接到服务器,那么它在语句上至少是合法的,并且没有明显的循环和错误模式,同时也不会占用太多的系统资源.
@在安全模式下执行
CPL脚本所做的任何行为,都不会使服务器产生混淆,对于那个服务器来说,用户是不可以访问的,或者没经过答应就影响其他用户的状态.作为补充说明,因为CPL脚本通常是在服务器上运行的,而用户是不可以在那上面运行普通代码的,因此,每一种语言以及它的运行环境都要经过精心设计,这样脚本才不会占用太多的网络资源,服务器的中心处理器的周期,存储系统和记忆体.
@机器和人都可以轻松的编写和分析
为了有最大的适应性,我们希望可以答应用户自行编写他们自己的脚本,或者通过定制来修改别人的脚本,使之成为自己的.但是,大多数用户对于同一样功能的函数都希望设立了相同的接口,然后有一个相关的程序可以专门为它创建脚本.这两种建议都会很好的实现它:非凡情况中,对于脚本编辑器来说,分析人编写的代码和机器自动生成的代码都很轻易.
@扩展
想要给一种语言添加些特性并不难,但要保证一件事,那就是现存的脚本可以继续工作,现存的服务器可以很轻易的识别出那些他们不了解的特征,并且把事情通知给用户.
@相互独立的信号细节
只要脚本相同,就应该一样可以使用,不管是按照什么协议指定的:SIP也好,H.323也好,普通的电话网络,或者是其他一些建立呼叫的方法.脚本它同时也应该不清楚地址的格式.(在需要进行语言描述时,我们采用SIP的术语,但对于其他系统,它也一样可以很简单的,轻易的使用.)对于把语言扩展成为其他形式的交流也一样很有用,就象电子邮件和传真.

推荐阅读