On Sun, 22 Jan 2012 10:48:36 -0800 (PST)
Darrell Anderson <humanreadable@...> wrote:

> > > HOW CAN WE BUILD A QUALITY PRODUCT IF NOBODY
> > UNDERSTANDS IT. Tim even
> > > mentioned he won't mess with it because he doesn't use
> > those languages. I
> > > think we have to be kidding ourselves if we are trying
> > to provide a
> > > "quality product".
> > 
> > Seems to me that we need to start by finding the answers to
> > these questions:
> > 
> > -Which languages are involved?  Looking at the source
> > in GIT, I think I see 
> >  Java, Perl,  Python, C#, C, Ruby, XPart (whatever
> > that is), and Javascript, 
> >  plus some other stuff (written mostly in Perl) that
> > appears to be 
> >  autogeneration/framework code for C# and Java.  Does
> > anyone see 
> >  anything that I may have missed or be misinterpreting?
> 
> Here is a complete list:
> 
> dcopc
> dcopjava
> dcopperl
> dcoppython
> kalyptus
> kdejava
> kjsembed
> korundum
> python
> qtjava
> qtruby
> qtsharp
> smoke
> xparts

smoke and kalyptus are the Java/C# generating code, and korundum seems
to be part of the Ruby binding, FWIW.

> > -Which of these languages do we have potential maintainers
> > for?
> > 
> > -Which of these bindings have actually been used for
> > creating software?
> >  Frex, Amarok has a Ruby dependency--will we need this
> > interface to
> >  maintain/further develop it?
> 
> I'm not qualified to make decisions. I can only offer that Java, JavaScript, Perl, Python, and 
>Ruby are popular and not going away any time soon. DCop is important to controlling Trinity 
>apps from external apps and scripts.

Perl is less popular than it once was, and Java programmers generally aren't big on using
platform-specific interface modules (it's counter to the philosophy of the language).
 
> To me, the important question is not which bindings to maintain but compiling the package. 
>If somebody wants to use their favorite language to hook into Trinity, let them have fun. 
>Right now the big issue is why compiling is such torture. Seems right now I'm the only 
>person trying. :)

Oh, ouch.  I just looked at the KDE 3.5.10 ebuild for kdebindings and found this:

# Broken and package.masked.
#       ~kde-base/korundum-$PV
#       ~kde-base/qtruby-$PV

# Omitted: qtsharp, dcopc, dcopjava, xparts (considered broken by upstream)

So the bulk of the code was broken pre-Trinity and likely was never fixed,
which could explain why it isn't compiling now.

Furthermore, if those bindings have been broken for that long and no one
has complained, chances are that no code ever used them (or if anything
did, it's long since migrated elsewhere).

Python, Perl, Javascript, and the non-dcop parts of the Java binding might
still work, but we need to either fix or kick the remainder.  Right now, I'm
leaning towards "kick", and it seems like most of the other people who've
weighed in do, too.

Given the manpower available and the general breakage level, I really do
think that focusing any effort that can be spared on the Python binding and 
dumping the rest if/when they break (unless a brave volunteer steps up) is 
likely the best way to go.