containing plasmoid crashes

Richard Dale richard.j.dale at gmail.com
Mon Jul 27 12:34:18 CEST 2009


On Sun, Jul 26, 2009 at 8:26 PM, Aaron J. Seigo<aseigo at kde.org> wrote:
> On Sunday 26 July 2009, David Baron wrote:
>> Do not the various interperators or VMs need be loaded in memory to service
>> their plasmoids
>
> so we need to:
>
> * have full ecma script bindings available
> * promote use of ecma script over other options
> * use ruby/python only as really needed (e.g access to additional libraries
> with python/ruby bindings)
It seems to me that you are forming conclusions, when I don't think we
have sufficient data yet. There are a whole pile of questions that I
don't know the answer to.

* How much memory and resources (non-shared and shared) does each
interpreter/VM take up?
* Would we have less crashes with only one scripting language binding is used?
* If we find a cause of a crash in one scripting language environment,
would it help to fix similar crashes in other scripting language
environments?
* What is the trade-off between attracting more programmers by having
several languages to choose from, and only one language?
* Would having too many languages to choose from actually put people
off, if none of them have a critical mass of community?
* Does ecma script scale? Is it suitable for complex applets as well
as simple ones? How does it compare with Ruby/Python?
* Should we take into account the fact that if someone programs
applets in say Python, then they have as easy way to begin learning
about how to write full scale KDE Python apps.
* If we have full ecma script bindings for applets do we really want
people to write full scale KDE applications in ecma script?
* If there are lots of people who know a little browser based
JavaScript coding, does it follow that we are likely to have more
people wanting to write Javascript applets? Or are KDE beginner
programmers perhaps not representative of a random sample of people
who know a little programming?

-- Richard


More information about the Plasma-devel mailing list