containing plasmoid crashes

[Aaron J. Seigo]

On Monday 27 July 2009, Richard Dale wrote:
> It seems to me that you are forming conclusions, when I don't think we
> have sufficient data yet.

it's at least in part due to watching amarok scripting and what they've been 
through.

> * How much memory and resources (non-shared and shared) does each
> interpreter/VM take up?

that's a good question. having more than one VM can't be good on that metric, 
though.

> * Would we have less crashes with only one scripting language binding is
> used? 

not likely, imo.

> * 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?

probably not; most of the crashes in the python scripting efforts seem to be 
in the python bindings and fixes to them probably don't affect other bindings?

> * What is the trade-off between attracting more programmers by having
> several languages to choose from, and only one language?

i'm not saying kill the ruby/pythong script engines. there is a difference 
between availability and preferred status, however.

> * Would having too many languages to choose from actually put people
> off, if none of them have a critical mass of community?

non-issue; i don't think having too many languages is a person issue but a 
practical issue of having the right things installed on the target system and 
overhead associated with multiple VMs running.

> * Does ecma script scale? Is it suitable for complex applets as well
> as simple ones? How does it compare with Ruby/Python?

looking at the widgets people are making, i don't think the language will be 
an impediment in any way. the difference is in what other libraries are bound 
to the target language. this is, in fact, one reason why ruby/python are so 
annoying to work with in such environments: they end up dragging in more and 
more dependencies and some scripts will work and others won't depending on the 
target system. this is exactly what amarok 1 ran into, according to their 
devs.

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

the python engine will always be there. they can use it as a gateway system. 
this is about what we prefer and encourage people who are primarily writing 
plasmoids.

> * If we have full ecma script bindings for applets do we really want
> people to write full scale KDE applications in ecma script?

probably not. i don't think that's relevant, though.

> * 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?

we don't know for sure, but the transferability of knowledge is quite 
obviously there to be taken advantage of.

> Or are KDE beginner
> programmers perhaps not representative of a random sample of people
> who know a little programming?

i don't see writing a plasmoid as necessarily the work of a KDE beginner 
programmer. it may be all the person is ever interested in, it may be 
something a person who works with KDE already does, etc.

and if it is easier to write something for plasma and successfully share it 
with others, perhaps that will change the demographic of "KDE beginner 
programmer" from what it is today. e.g. this could grow our reach rather than 
tap into the same group we already do.

but this is all about something that is completely separate from the primary 
metric of choosing which language(s) to emphasize: what will make for the best 
experience in Plasma?

that's measured by:

* what we can build security around
* what we can easily ensure is deployed and available on target systems so 
people can actually run these things
* what will encourage more plugins to be written

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090727/55c9b68c/attachment.sig