On Sun, Jul 26, 2009 at 8:26 PM, Aaron J. Seigo<ase...@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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
