档案
日志
相册
视频
分享
2006-07-11 | [KDE 新闻] Sebastian Sauer谈kross(2006-07-9)
koffice1.5中增加了kross，这是一个支持多语言脚本插件的一个框架。在KDE-Files.org提供给krita及kexi大量这类的插件。为进一步了解这项技术以及其由来，KDE新闻采访了作者Sebastian Sauer。下面是采访内容，你可以找到如何使用kross。
什么是kross？
kross是koffice的脚本引擎，它提供了一套完整的框架以在原程序中透明地嵌入脚本解释器，将动态与静态世界联系在一起。
kde提供了一套丰富的不同编程语言的开发工具。如PyQt/PyKDE, QtRuby/Korundum，你甚至可以用Java开发KDE相关程序，而微软的C#也被支持了。
如果仅仅是达到内嵌脚本的目标的话，QSA与kjsEmbed都已经提供了一个内嵌java脚本的解释器，虽然它们只实现了现有模块与第三方支持语言如Python或Ruby等的较少的一部分功能。目前还没有如CPAN般的由庞大社区开发的无所不包的维护或改进中的可重复利用的第三方模块集出现。
开源社区充满了选择、可重复套用的函数及灵活性。那么为什么不增加可以嵌入应用软件的编程语言的数量呢？试想在你自己的程序中编写代码以嵌入Ruby解释器，然后编写更多的代码以支持python，LUA以及Perl等，然后你必须在你的程序内部实现针对每一种脚本语言的绑定，并且这种做法只能针对单个应用程序因为每个程序需要绑定的做法是不同的，而程序开发者更喜欢只用一种脚本语言，于是到了最后大多数程序员只能是为了在单个的应用程序中嵌入脚本而重复地发明轮子。
为此我们就需要一套透明而又脚本解释器无关的方案，以便于处理这种事件。这就是kross出现的契机。
首先它是透明的，因为应用kross的程序根本不必知道用哪一种脚本语言。所有的程序只需要知道存在一个提供脚本功能的程序库。事实上这是因为kross不仅可以在一个程序插件中被提供和使用(那是krita与kexi使用kross的方式)，如果程序喜欢的话它也可以被当作是一个K组件。
所有的应用程序需要的是所加载的插件向它传递对象实例。插件与kross明白如何去运用程序提供的绑定代码去操作这些实例，而操作的本身是与解释器无关的。这些绑定的代码实现了与kross的交接，而kross则具体负责脚本的后端运行。
事实上甚至kross的核心都不知道哪个解释器将最终实现这些脚本代码，或者说不知道脚本是如何被实现的。所有这些都是运行时由动态加载的特定解释器完成的。这意味着我们对解释器相关代码和与应用程序中与解释器无关的代码进行了严格地隔离。更好的是，解释器相关代码可以被单独打包，只有在用户真正需要它的时候才将其安装上去。那样就使我们节省出充足的空间以便于嵌入例如java,Mono,LUA或者Prolog等的脚本，只要哪天有人认为他的程序需要（某种脚本语言的支持），我们就可以将之引入而无需考虑任何优先依赖。所有用上kross的程序从那以后就可以选择最新的解释器，而不用在程序或是绑定代码中增加一行代码，甚至不用重新编译现有程序。
目前kross在哪里得到应用？
最近它被用于koffice。准确的说应该是koffice1.5中的kexi与krita提供了全部的Python和Ruby脚本。KSpread将从KOffice2.0中开始支持kross，KWord等KOffice程序也计划采用它。
Kross支持什么脚本语言？
Python和Ruby已被完整地集成并被Kjs/KjsEmbed支持，Java的支持也处于计划中了。这两种已被支持的解释器在实现联接时只是处理一小部分的文件（如果我没记错的话，是大约5%），主要的工作是Kross核心程序完成的，是它使得应用程序与解释器相互对话。而理论上令一个解释器与另一个解释器相互沟通应该也不是很困难。
我们只在现有技术中加入了一步就避免了日后的重复性劳动。你们也能够在原来的KDE程序中发挥出PyQt,PyKDE,QtRuby和Korundum全部力量了。你们也可以构建复杂的图形用户界面，将它们动态地嵌入你们的程序中，让他们连接信号与模块，交换对象实例，操控你们的K程序，读取DCOP,QWidget类和你想存档的任何东西。例如在Kexi，我们决定我们不再依赖PyQt显示一个简单的图形用户界面以实现“数据库表格或查询XHTML文件”，这大约只是100行python代码。于是我们就回到TkInter中另写了100行python代码，以便在没有安装PyQt的情况下也能运行。你猜怎么样，它们运行的很好。理论上甚至PyGtk也能够这样运行（我从未试过），这意味着我们可以在不依赖它的情况下访问到Gtk了。
您能给出一个用法的例子吗？
例如Kexi已经开始开发了一大堆脚本来扩张程序的功能。我们也提供了“获得新脚本”的功能以从网上安装与升级脚本包。
在KDE-Files.org ,我们为kexi提供了完整的web服务。我们提供了加载了一些优秀的外部模块的拷贝中心，其中python的脚本可将Kexi的数据库整合为如QtSQL数据库或者与Excel兼容的CSV文件。这些脚本以前只是大概的写了点，但现在已基本可用了。
怎么使开发者们在他们的程序中加入kross支持呢？
Cyrille Berger写了一篇优秀的指南。我们已经设法在几个星期中将所有的kross内部代码以模板的形式隐藏起来。让我们看一个简单的例子吧。（可以在trunk/koffice/kspread/scripting中看到详细的代码）
// We like to wrap that class and publish the myFactoryMethod-method to scripting languages.
class MyNativeClass
{
public:
MyNativeClass* myFactoryMethod(const QString& name) {...}
}
// So, here is the wrapper class
class MyWrapperClass : Kross::Api::Class
{
public:
MyWrapperClass(MyNativeClass* instance)
{
// just publish the method above and say who should handle
// the arguments by defining them as template-arguments.
this->addFunction1
("myFactoryMethodName", instance, &MyNativeClass::myFactoryMethod);
}
}
我们现在能够在脚本代码中调用factory-method，并得到一个MyWrapperClass的实例。所有类型都被动态地包装，而我们甚至能够委托方法动态调用它们。
对比DBUS,KJSEmbed和Kommander，kross的优势在哪里?
DBUS是一项伟大的工作，但它的主要领域在于IPC/RPC（Inter-process and remote-process），而KJSEmbed和Kross则是在应用程序中嵌入脚本的领域中。这样脚本就可以运行在一个程序的地址空间中，并能够操纵程序。
KJSEmbed是KDE java脚本的重量级绑定，它不允许你将之与其它脚本语言整合。用户需要使用javascript或者不用任何脚本。这样就不可能使用现有的解决方案，如PyQt, QtRuby, Java 或 LUA。
Kommander是一个非常优秀的工具，它可以轻松地与用设计器构建结合构建GUI并使用DCOP(在KDE4中被DBUS代替)。它与我所设想的灵活地脚本解决方案非常接近。也许有天我们会将它与Kross整合在一起，并以一种灵活而快速透明的进程脚本解决方案扩展它优秀的用户界面。
为什么Kross脚本比直接在程序中写入插件要好？
这是一个困难的问题，因为这会上升到用户对C++或是如python之类的脚本语言的喜好的高度，而我猜想这不会出现一个正确的答案。
使用kross脚本会出现什么安全问题？
这是我们当前所遇到的最大的问题。Python不能处理不安全因素、不可信的脚本，也没有提供任何如sandbox那样的运行环境。而Ruby支持安全等级，我将zope受限的python环境引入kross，但我不能确定它们能与java的sandbox那么安全。我们会试着将用kexiwiki Scripting page里罗列的标记过的代码以尽量减少危害。但那不能视为最有效与最安全的解决安案。所以，目前我还不能找到比使用java更好的办法对待不可信的脚本或是扩展KJSEmbed4以便处理不安全代码。
KOffice将会具备宏脚本吗？
这是我们工作的另一项任务。我的大学里的一个团队去年曾为kexi的宏命令整合做了工作。在这一点上我得多谢柏林工业学院的Hr.Christoph Knabe，他在我们之后为宏前端做了很多的工作。目前的状态是它还很幼稚而不能够广泛的应用。也许明年我们可以讨论有关它的一些细节。
Kross将会应用于KOffice之外的程序吗？
我希望是这样。但我猜每一个开发者都不得不去考虑诸如它的应用是否有意义，程序的用户们会不会喜欢一种语言无关的脚本解决方案。在年底前它的所有特征都才会确定，而在这之前什么都有可能。
您是如何提出Kross的构想的？
让我先来回答“为什么这个家伙会有这个想法去做kross，还有为什么他选择了这个丑陋的以K为首的名字？”这个大家都有可能有的想法。其实在我加入kexi的时候，我开始在当时的Kexi wiki-page寻找一个我们能够做到的脚本解决方案。事实上，一些人，如Cedric Pasteur or Lucijan Busch等早就有了这么一个整合一个解释器无关的解决方案了，并将之写在了Wiki上，而这项工作的名字就叫作"Kross"。我绝对赞同那些想法，并且我开始去实现它。
Kross的实现的困难有多大？
kross的实现很难，并且一直都很难。最主要的原因是我想做到最好。每一次其它程序员问我kross是否已经被我搞定的时候，我都回答说“还没有，因为我个人觉得它还很稚嫩，并且它的应用程序接口可能还会有很大的改变”。最后有位程序员不满意我通常的回答，于是着手应用它。那无疑是正确的决定，从那时开始，kross就从一个不断变动的程序员的目标转变为一个非常稳定且可用的解决方案。在此，我向Cyrille Berger表示极大的感谢。
在MS windows平台上有与kross相似的程序吗？kross与VBA的范畴相似吗？
VBA只是一个单一的脚本后端。Kross有它自己的理念：它向解释器提供了一个提取层，并隐藏了试图使用脚本语言的应用程序的差别。它借鉴了很多.net的思想，但没用采用.net的代码，专利，也没有对用户封闭代码。它利用了现有技术，并提供了对它们的访问方法，但在实现过程中没有引入任何依赖。
Kross基本完成了吗？或它还在开发中，特性仍在增减当中吗？
我以前说它仍在变动的话曾吓走了很多潜在的用户（但我现在不再那么说了）。但是对它仍然还有许多工作要做。例如我想将KJS/KJSEmbed 和 Java都整合进去。另一个目标是在其内部大量使用模板以加快它的速度，并全面透明地采用DBUS技术整合。我也希望找点时候想想如何使它可以与伟大的Kommander与联接。
我们在哪里可以找到更多与之有关的东西？
在http://kross.dipe.org
如果有任何问题，你们都可以直接通过mail-at-dipe.org找我，或者在Freenode 的IRC上的#koffice频道找到我，我暂时还用“dipesh”这个昵称。
什么是kross？
kross是koffice的脚本引擎，它提供了一套完整的框架以在原程序中透明地嵌入脚本解释器，将动态与静态世界联系在一起。
kde提供了一套丰富的不同编程语言的开发工具。如PyQt/PyKDE, QtRuby/Korundum，你甚至可以用Java开发KDE相关程序，而微软的C#也被支持了。
如果仅仅是达到内嵌脚本的目标的话，QSA与kjsEmbed都已经提供了一个内嵌java脚本的解释器，虽然它们只实现了现有模块与第三方支持语言如Python或Ruby等的较少的一部分功能。目前还没有如CPAN般的由庞大社区开发的无所不包的维护或改进中的可重复利用的第三方模块集出现。
开源社区充满了选择、可重复套用的函数及灵活性。那么为什么不增加可以嵌入应用软件的编程语言的数量呢？试想在你自己的程序中编写代码以嵌入Ruby解释器，然后编写更多的代码以支持python，LUA以及Perl等，然后你必须在你的程序内部实现针对每一种脚本语言的绑定，并且这种做法只能针对单个应用程序因为每个程序需要绑定的做法是不同的，而程序开发者更喜欢只用一种脚本语言，于是到了最后大多数程序员只能是为了在单个的应用程序中嵌入脚本而重复地发明轮子。
为此我们就需要一套透明而又脚本解释器无关的方案，以便于处理这种事件。这就是kross出现的契机。
首先它是透明的，因为应用kross的程序根本不必知道用哪一种脚本语言。所有的程序只需要知道存在一个提供脚本功能的程序库。事实上这是因为kross不仅可以在一个程序插件中被提供和使用(那是krita与kexi使用kross的方式)，如果程序喜欢的话它也可以被当作是一个K组件。
所有的应用程序需要的是所加载的插件向它传递对象实例。插件与kross明白如何去运用程序提供的绑定代码去操作这些实例，而操作的本身是与解释器无关的。这些绑定的代码实现了与kross的交接，而kross则具体负责脚本的后端运行。
事实上甚至kross的核心都不知道哪个解释器将最终实现这些脚本代码，或者说不知道脚本是如何被实现的。所有这些都是运行时由动态加载的特定解释器完成的。这意味着我们对解释器相关代码和与应用程序中与解释器无关的代码进行了严格地隔离。更好的是，解释器相关代码可以被单独打包，只有在用户真正需要它的时候才将其安装上去。那样就使我们节省出充足的空间以便于嵌入例如java,Mono,LUA或者Prolog等的脚本，只要哪天有人认为他的程序需要（某种脚本语言的支持），我们就可以将之引入而无需考虑任何优先依赖。所有用上kross的程序从那以后就可以选择最新的解释器，而不用在程序或是绑定代码中增加一行代码，甚至不用重新编译现有程序。
目前kross在哪里得到应用？
最近它被用于koffice。准确的说应该是koffice1.5中的kexi与krita提供了全部的Python和Ruby脚本。KSpread将从KOffice2.0中开始支持kross，KWord等KOffice程序也计划采用它。
Kross支持什么脚本语言？
Python和Ruby已被完整地集成并被Kjs/KjsEmbed支持，Java的支持也处于计划中了。这两种已被支持的解释器在实现联接时只是处理一小部分的文件（如果我没记错的话，是大约5%），主要的工作是Kross核心程序完成的，是它使得应用程序与解释器相互对话。而理论上令一个解释器与另一个解释器相互沟通应该也不是很困难。
我们只在现有技术中加入了一步就避免了日后的重复性劳动。你们也能够在原来的KDE程序中发挥出PyQt,PyKDE,QtRuby和Korundum全部力量了。你们也可以构建复杂的图形用户界面，将它们动态地嵌入你们的程序中，让他们连接信号与模块，交换对象实例，操控你们的K程序，读取DCOP,QWidget类和你想存档的任何东西。例如在Kexi，我们决定我们不再依赖PyQt显示一个简单的图形用户界面以实现“数据库表格或查询XHTML文件”，这大约只是100行python代码。于是我们就回到TkInter中另写了100行python代码，以便在没有安装PyQt的情况下也能运行。你猜怎么样，它们运行的很好。理论上甚至PyGtk也能够这样运行（我从未试过），这意味着我们可以在不依赖它的情况下访问到Gtk了。
您能给出一个用法的例子吗？
例如Kexi已经开始开发了一大堆脚本来扩张程序的功能。我们也提供了“获得新脚本”的功能以从网上安装与升级脚本包。
在KDE-Files.org ,我们为kexi提供了完整的web服务。我们提供了加载了一些优秀的外部模块的拷贝中心，其中python的脚本可将Kexi的数据库整合为如QtSQL数据库或者与Excel兼容的CSV文件。这些脚本以前只是大概的写了点，但现在已基本可用了。
怎么使开发者们在他们的程序中加入kross支持呢？
Cyrille Berger写了一篇优秀的指南。我们已经设法在几个星期中将所有的kross内部代码以模板的形式隐藏起来。让我们看一个简单的例子吧。（可以在trunk/koffice/kspread/scripting中看到详细的代码）
// We like to wrap that class and publish the myFactoryMethod-method to scripting languages.
class MyNativeClass
{
public:
MyNativeClass* myFactoryMethod(const QString& name) {...}
}
// So, here is the wrapper class
class MyWrapperClass : Kross::Api::Class
{
public:
MyWrapperClass(MyNativeClass* instance)
{
// just publish the method above and say who should handle
// the arguments by defining them as template-arguments.
this->addFunction1
("myFactoryMethodName", instance, &MyNativeClass::myFactoryMethod);
}
}
我们现在能够在脚本代码中调用factory-method，并得到一个MyWrapperClass的实例。所有类型都被动态地包装，而我们甚至能够委托方法动态调用它们。
对比DBUS,KJSEmbed和Kommander，kross的优势在哪里?
DBUS是一项伟大的工作，但它的主要领域在于IPC/RPC（Inter-process and remote-process），而KJSEmbed和Kross则是在应用程序中嵌入脚本的领域中。这样脚本就可以运行在一个程序的地址空间中，并能够操纵程序。
KJSEmbed是KDE java脚本的重量级绑定，它不允许你将之与其它脚本语言整合。用户需要使用javascript或者不用任何脚本。这样就不可能使用现有的解决方案，如PyQt, QtRuby, Java 或 LUA。
Kommander是一个非常优秀的工具，它可以轻松地与用设计器构建结合构建GUI并使用DCOP(在KDE4中被DBUS代替)。它与我所设想的灵活地脚本解决方案非常接近。也许有天我们会将它与Kross整合在一起，并以一种灵活而快速透明的进程脚本解决方案扩展它优秀的用户界面。
为什么Kross脚本比直接在程序中写入插件要好？
这是一个困难的问题，因为这会上升到用户对C++或是如python之类的脚本语言的喜好的高度，而我猜想这不会出现一个正确的答案。
使用kross脚本会出现什么安全问题？
这是我们当前所遇到的最大的问题。Python不能处理不安全因素、不可信的脚本，也没有提供任何如sandbox那样的运行环境。而Ruby支持安全等级，我将zope受限的python环境引入kross，但我不能确定它们能与java的sandbox那么安全。我们会试着将用kexiwiki Scripting page里罗列的标记过的代码以尽量减少危害。但那不能视为最有效与最安全的解决安案。所以，目前我还不能找到比使用java更好的办法对待不可信的脚本或是扩展KJSEmbed4以便处理不安全代码。
KOffice将会具备宏脚本吗？
这是我们工作的另一项任务。我的大学里的一个团队去年曾为kexi的宏命令整合做了工作。在这一点上我得多谢柏林工业学院的Hr.Christoph Knabe，他在我们之后为宏前端做了很多的工作。目前的状态是它还很幼稚而不能够广泛的应用。也许明年我们可以讨论有关它的一些细节。
Kross将会应用于KOffice之外的程序吗？
我希望是这样。但我猜每一个开发者都不得不去考虑诸如它的应用是否有意义，程序的用户们会不会喜欢一种语言无关的脚本解决方案。在年底前它的所有特征都才会确定，而在这之前什么都有可能。
您是如何提出Kross的构想的？
让我先来回答“为什么这个家伙会有这个想法去做kross，还有为什么他选择了这个丑陋的以K为首的名字？”这个大家都有可能有的想法。其实在我加入kexi的时候，我开始在当时的Kexi wiki-page寻找一个我们能够做到的脚本解决方案。事实上，一些人，如Cedric Pasteur or Lucijan Busch等早就有了这么一个整合一个解释器无关的解决方案了，并将之写在了Wiki上，而这项工作的名字就叫作"Kross"。我绝对赞同那些想法，并且我开始去实现它。
Kross的实现的困难有多大？
kross的实现很难，并且一直都很难。最主要的原因是我想做到最好。每一次其它程序员问我kross是否已经被我搞定的时候，我都回答说“还没有，因为我个人觉得它还很稚嫩，并且它的应用程序接口可能还会有很大的改变”。最后有位程序员不满意我通常的回答，于是着手应用它。那无疑是正确的决定，从那时开始，kross就从一个不断变动的程序员的目标转变为一个非常稳定且可用的解决方案。在此，我向Cyrille Berger表示极大的感谢。
在MS windows平台上有与kross相似的程序吗？kross与VBA的范畴相似吗？
VBA只是一个单一的脚本后端。Kross有它自己的理念：它向解释器提供了一个提取层，并隐藏了试图使用脚本语言的应用程序的差别。它借鉴了很多.net的思想，但没用采用.net的代码，专利，也没有对用户封闭代码。它利用了现有技术，并提供了对它们的访问方法，但在实现过程中没有引入任何依赖。
Kross基本完成了吗？或它还在开发中，特性仍在增减当中吗？
我以前说它仍在变动的话曾吓走了很多潜在的用户（但我现在不再那么说了）。但是对它仍然还有许多工作要做。例如我想将KJS/KJSEmbed 和 Java都整合进去。另一个目标是在其内部大量使用模板以加快它的速度，并全面透明地采用DBUS技术整合。我也希望找点时候想想如何使它可以与伟大的Kommander与联接。
我们在哪里可以找到更多与之有关的东西？
在http://kross.dipe.org
如果有任何问题，你们都可以直接通过mail-at-dipe.org找我，或者在Freenode 的IRC上的#koffice频道找到我，我暂时还用“dipesh”这个昵称。
分享
评论
想第一时间抢沙发么？