Using scripting languages for KDE4 main modules

[Alfredo Beaumont]

Igandea 01 Urria 2006 17:47(e)an, Leo Savernik(e)k idatzi zuen:
> 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)

This is how I see it:

- A writes support for new important formula for kspread in ruby in a week
- B,C,D see the formula is good, and is happy to see she can use it
- E,F,G,H use the formula but it is slow, and complain
- I decides that it is such an important feature and codes it in C++, after 
some months

If there's no such a possibility we wouldn't have B,C,D,E,F,G,H using it. I 
guess it's better to have an important slow feature that lacking and 
important feature. And if it's important, I guess it'll be coded natively 
when it has shown its relevance.

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

I don't think krita will need either python nor ruby for loading.

> 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

-- 
Alfredo Beaumont Sainz
http://www.alfredobeaumont.org/blog.cgi