Malaga Discussions II

[Sebastian Sauer]

> However, KJSEmbed is also excellent at this point, and I'm pretty sure
> it's
> 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 
together!

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
> more
> 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
> pitfall.

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]
http://www.dipe.org/public_key.asc
Fingerprint: 8F1E 219B 16E6 4EC7 29CC F408 E193 65E2 9134 2221
Coder in http://www.koffice.org/kexi && http://www.kmldonkey.org