> 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.
Well I did some benchmark with krita 1.6svn. Using ps, if anyone knows a 
better way to profile memory consumption, I am ready to give it a try.
The test is the following:
 launch krita
 creates a 1x1 pixel image (to limit the memory increase of memory due to 
operations on a big image)
%mem
2.2 krita at start
2.3 krita after running the ruby invert filter
2.4 krita after running the python invert filter
2.4 krita after running the python invert filter a second time
2.4 krita after running the C++ invert filter

Then after removing the kross plugins (and therefor no link anymore to 
ruby/python library):
%mem
2.2 krita
2.2 krita after running the C++ invert filter

0.1% of memory correspond to 2Mo of memory on my system (I wish I had a better 
way to measure it)
Which means ruby and python's library with debug symbols increase the memory 
taken by an application of 2Mo each... I don't consider it memory hogging and 
drowning performance.

A final test to see the cost of the binding:
%mem
2.7 krita after running a script that loads the korundum binding

It would be interesting to know why that increase so much the memory 
consumption, but for kross we were thinking of adding some very basic binding 
to ui to avoid loading the full binding for the language.

> 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.
that depends how you construct your application, krita is splitted in two : on 
one side the core libraries, and then plugins which brings functionality to 
krita. Core libraries are C++ and will remain C++ only. Kross is one of the 
plugins, and each of the interpreter (ruby, python, kjs) is a plug-in that is 
only loaded if the interpreter is available. That means, if python is not 
available, in the worse situation, some functions are just not available, 
filters or automation mostly.

-- 
--- Cyrille Berger ---