[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Moving kross(kexi/scriptingcore) in libs
From:       Jaroslaw Staniek <js () iidea ! pl>
Date:       2005-11-02 14:57:51
Message-ID: 4368D3EF.4030903 () iidea ! pl
[Download RAW message or body]

Gary Cramblitt said the following, On 2005-11-02 13:49:

> On Tuesday 01 November 2005 05:30 pm, Cyrille Berger wrote:
> 
>>Hello,
>>
>>First, a little explanation of what Kross is, it's the "kexi scripting
>>bridge". It allows to add support for different scripting language (well,
>>currently, only python, but more to be add). More info can be found at
>>http://www.kexi-project.org/wiki/wikiview/index.php?Scripting
>>
>>In the beginning, it was developed by dipesh for kexi, so it was logical to
>>have kross in kexi/scriptingcore, but now, I am working on a plugin for
>>krita (not commited yet), that uses kross to add scripting capabilities. So
>>it might be a good idea to move it from kexi/ to libs/. (and maybe some
>>other koffice applications might take benefit of it ?)
>>
>>What do you think ?
> 
> 
> Here's what I know about scripting: I can spell it.
> 
> I do have a few reactions, which you should interpret in the above context.
> 
> 1.  If moved to lib, make sure it doesn't cause build problems for folks who 
> don't have the dependencies, such as Java, Python, whatever.

Hmm, read some of the KROSS docs or what KROSS authors said here: KROSS 
doesn't add dependency on anything except KDE/Qt. Thanks to plugins, Python is 
optional as well as any othe language that could be supported.

If you don't want (can't) write scripts, you could use macros, without a need 
for installing language packages.

OTOH, I agree we rather should not just play with 'as many languages as 
possible' because then Kexi project files/databases (and other KO apps' data) 
will be no longer compatible between different computers because not every 
user will have all language plugins installed.
If I could vote, we should think about at most two languages and focus on 
them. One of them is already selected: Python.

I guess, one day, for users convenience, subpackages for language bindings 
should be at least "suggested" addition for main KROSS (or kolibs) package.

> 2.  At aKademy, the scripting guys were telling me that scripting can be added 
> to KDE applications without having to do any coding within the application 
> itself.  So I'm surprised/confused by this.

There's nothing coming for free. You can have developed easy bindings using 
DCOP/DBUS but very unefficient. We're also talking about a code for data 
processing, reportin, drawing..., not just executing actions.

Also note that C++ API of an app is not the same as scripting api: some 
functionality needs to be heavily simplified. Otherwise you will end up with 
OO.org Calc-like macros that require you to instantiate wrappers implementing 
Sun's UNO, before you can, say, fill some cells with your data.

> 3.  Make sure this does not introduce security vulnerabilities, ala Microsoft 
> Word Macro viruses, into KOffice.  I see you've addressed security on the 
> Kross webpage, but I don't understand most of what that says. 
 > Bottom line:
> Even one report of a KOffice virus and we're sunk, so make sure that doesn't 
> happen.  It appears that simply by sending a kexi data file to a victim, and 
> convincing them to open it, a virus writer can gain access to the entire 
> facilities of the scripting engine (Python or whatever), and wreak havoc on 
> the entire system.  

Only user's account.

 > Sounds very risky to me.

FYI: You've mentioned "I don't understand most of what that says". So my 
advice for you could be, since you may have no idea about secure script 
frameworks, to learn what sandboxes /limited execution environment mean.

Or look at a web browser's javasript interpreters - they (should?) have no 
access to files and critical system functions. This is how KROSS is designed too.

Knowing the riks of exchanging executable packages (it's also valid for DEBs 
and RPMs), KROSS authors have also plans for digital-signing framework to 
allow users to avoid such situations.

-- 
regards / pozdrawiam,
  Jaroslaw Staniek / OpenOffice Polska
  Kexi Developer:
      http://www.kexi-project.org | http://koffice.org/kexi
  KDE3, KDE4 libraries for developing MS Windows applications:
      http://wiki.kde.org/tiki-index.php?page=KDElibs+for+win32
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]