[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Guidance in KDE Admin
From:       Leo Savernik <l.savernik () aon ! at>
Date:       2008-03-27 19:51:11
Message-ID: 200803272051.12672.l.savernik () aon ! at
[Download RAW message or body]

Am Donnerstag, 27. März 2008 schrieb Nicolas Ternisien:
> > > It looks like Guidance introduces a hard python dependency into KDE. I
[...]
> Yes, IIRC, it was a request from Aaron Siego to open KDE main tree to other
> languages than C++. Python perfectly fits in my opinion this request. What
> is your main problem about this Leo ? Of course, if it was Mono or Java, I
> think the problem should be different (particularly Mono, because Java 7 is
> going to be GPL2), but in this case, this is a open source language without
> any problem, and really well supported.
>
[...]

It's not about the license. It's about bloat. A large share of KDE's 
cohesiveness and memory efficiency can be attributed to mostly settling onto 
one binding which is C++. I don't want to see that advantage being given up 
thoughlessly.

Once we have opened the door for arbitrary bindings of KDE core application we 
cannot close it anymore. Therefore, I suggest a very conservative approach 
and only permit non-built-in bindings (everything beyond C/C++/kjs/QtScript) 
when the additional memory consumption of the application can be justified.

If we don't precisely define the scope of which external script engines we 
actually permit in core KDE distributions, we'll accumulate script engine 
bloat. This makes KDE a less favourable candidate on emerging small scale 
devices like the eeePC and other environments where memory consumption cannot 
be fully ignored.

Therefore, the introduction of runtime dependencies on a single script engine 
must not represent a carte blanche for a neverending influx of even more 
script engine dependencies. Up to now, we could easily keep the status quo by 
telling people, "sorry, no external dependencies".

By permitting a hard dependency on python we also have to permit a hard 
dependency on ruby (because the ruby zealots won't stop nagging until they're 
on par ;-) ). From there it's only a matter of time we'll actually introduce 
überheavy dependencies onto java and mono.

So I'm not convinced that the benefits of introducing python KDE core 
applications outweigh the disadvantages.

mfg
	Leo
[prev in list] [next in list] [prev in thread] [next in thread]