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

List:       kde-core-devel
Subject:    Re: Using scripting languages for KDE4 main modules
From:       Leo Savernik <l.savernik () aon ! at>
Date:       2006-10-01 15:47:09
Message-ID: 200610011747.10972.l.savernik () aon ! at
[Download RAW message or body]

Am Sonntag, 1. Oktober 2006 13:07 schrieb Boudewijn Rempt:
> > For the latter case, there's no decision on official language, since
> > there doesn't have to be. Applications can be written using any binding.
> > But, as this thread has proven, the basic applications must be in C++ so
> > that memory consumption stays low.
>
> I haven't seen "proof", just some assertions, but aside from that, hadn't
> we better define a list of "the basic applications" then -- Leo's list is
> obviously much too large. If the list of basic applications for which C++
> is required, then people who prefer a little more efficiency in their
> development process know what's left for them.

My list is purportedly encompassing to prevent this:
- A writes support for new important formula for kspread in ruby
- B writes new important dialog for kspread in python
- C writes new important other functionality for kspread in fooblargh
- ...
(where "new important" means functionality already contained in excel whose 
support is considered crucial to be perceived as a "full blown" app)

Then we already have three script interpreters+runtimes+bindings hogging 
memory and drowning performance. The user now has two choices: Doing without 
scripting languages, leading to bug report "kspread doesn't support 'foo'", 
or going through the hassle of setting up all the dependencies, leading to 
bug report "kspread is ten times as slow as and incurs tenfold memory usage 
compared to excel doing 'foo'".

Another hypothetical example (not that far fetched) pretending krita needs 
python and ruby binding to work:
- kword user doesn't have python and ruby installed.
- wants to paste image into kword
- krita flake refuses to load
=> no images in kword documents.

The problem of allowing arbitrary (even if restricted to a small number) 
scripting languages leads either to a fast KDE environment that is crippled 
or a slow, memory eating, fully functional one.

Therefore I suggest that no core component and core application that *is 
needed to make KDE being perceived as fully functional* is written in any 
scripting language except those shipped within KDE (kjsembed), and even that 
one shouldn't be used too liberally.

I absolutely don't care about external extensions that are not released within 
the basic KDE distribution. They may depend on whatever scripting language 
they like.

>
[...]

mfg
	Leo
[prev in list] [next in list] [prev in thread] [next in thread]