Malaga Discussions II
mail at dipe.org
Mon Aug 29 01:17:41 BST 2005
> However, KJSEmbed is also excellent at this point, and I'm pretty sure
> actually being used for this purpose already. And of course there's also
> QSA to consider.
> Also this would be the solution with least impact, since KDE will be
> shipping KJS *anyways*, it makes sense to build on that instead of using a
> whole different script bindings layer.
Scripting is much more then providing an alternate syntax to C++ and to be
able to extend my Qt/KDE-app with easily changable scripts that doesn't need
a whole recompile to take affect. It's much more then about providing some
restricted sandbox and plugin-mechanism. It's also about briding worlds
KJS/QSA are (somewhat) based on Qt and therefore it's pretty easy to use them
in Qt/KDE applications. But it's strengthens are also the biggest
disadvantage. Why? Well, cause we are limited to the functionality kjs/qsa
provides. There is no cpan-archive for kjs/qsa/ecma that provides e.g. access
to a Cobol sam-file and extend your application that way with a
import-/export-filter written in scripting code. There is no jdbc kjs-module
around that could be used from within ecma-script or a ldap module...
>> > [...] kjs/qsa [...]
>> Quit funny cause the feedback I got last year from majority of users and
>> developers is, that they would like to have python or <put your fav
>> interpreter her> as preferred language instead of ecma like scripts.
> Well in the end the difference between Python, Ruby, and JS is becoming
> and more just syntactic sugar and standard library differences. Although
> JS will be able to use Qt/KDE's libraries so I don't see that as a huge
That is the question. Is it easier to build a java-bridge to e.g. access my
favorit databases via JDBC transparently from within Qt/KDE (for sure without
letting it depend on java on compiletime, so load interpreter-modules at
runtime if avaiable) or is it easier to just reinvent jdbc / write some
jni-wrappers? and if I choose to use wrappers the solution is for my app only
rather then something each app is able to use.
>> As already sayed above that doesn't mean to maintain a bunch of
>> equivalent solutions for all existing interpreterlanguages like done
>> today, rather then providing a plugin-framework where somebody is able to
>> put his own scripting-binding in and use it as first class citizen even
>> if not official supported by the KDE-project.
> It's a great idea but I guess we'll have to wait to see about the
> technical feasibility of it. ;)
More initial work sometimes leads to better / more flexible solutions. I also
would like to remind anybody interessted in that topic, that there is at the
moment a lot of progress on the try to get the openoffice UNO-API out of
oo.org for reusing. No proposal, but the API provides at least a good
overview of what is possible with a flexible scripting-solution...
Sebastian Sauer aka dipesh[sebsauer]
Fingerprint: 8F1E 219B 16E6 4EC7 29CC F408 E193 65E2 9134 2221
Coder in http://www.koffice.org/kexi && http://www.kmldonkey.org
More information about the kde-core-devel