[rtg] Traffic is wrapping

[Leech, Jonathan]

Bill,

Another thought I had regarding language choice, especially since you
mentioned Python and Ruby. There exist JPython and JRuby, and both
appear to be fairly mature implementations, and arguably in some areas
better than the native languages. Kind of similar to the way the
different .Net languages can share common API's and run together on the
same runtime.

The modular nature of JRTG would allow one to write whatever feature in
whatever language, so long as the language compiles to Java bytecode and
will run in the JVM.

-Jonathan

-----Original Message-----
From: bill fumerola [mailto:billf at mu.org] 
Sent: Wednesday, April 09, 2008 4:30 PM
To: Leech, Jonathan
Cc: rtg at lists.grdata.com
Subject: Re: [rtg] Traffic is wrapping

On Tue, Apr 08, 2008 at 03:16:10PM -0600, Leech, Jonathan wrote:
> What's on sourceforge is intended to be a starting point. I don't have

> any users I know of other than me, so I haven't prioritized updating 
> the code.

ok.

> However, JRTG hasn't changed much since the version that's up there. 
> One or two bug fixes. Also I've built an RRD module that uses RRD4J to

> write values to files instead of a database. I have also been kicking 
> around the idea of building a TargetParser that can read Cricket's 
> equivalent of a targets file.

normally, i like consolidating efforts on projects. unfortunately, the
only way i see to leverage work being done in your project and rtg would
be to use something like thrift[1] and seperate out the poller, config
parser, database insertion, etc. people could run different parts of the
system on different machines, JRTG could be used for the database layer,
the C poller could be used to feed it, etc.

this is just dreamworld stuff. i've wanted to seperate some of the C
code into seperate daemons for various reasons. thrift would be great,
but...

thrift doesn't have C bindings yet (and while many desire, it's a tough
nut to crack). that kills that idea unless we convert the existing rtg
to C++, which would be Yet Another Rewrite.

think of this, though... with thrift we could have a perl targetmaker, a
python config parser, a C or ruby poller, a java database aggregator, an
almost infinite amount of combinations.

it's neat. it also would require serious rototilling. not gonna happen.

> Thanks for the link to Joel, I hadn't read that one. He makes some 
> very good points. My particular school curriculum was mainly C++, a 
> little assembly. I already had a background in C and C++ prior to 
> college so I was immune to the weed out courses Joel mentions. I think

> the problem nowadays isn't in teaching Java, its the failure of the 
> schools to teach something hard enough to weed out the incapable.

i wasn't implying you were one of the people he mentions. it's just a
good summary on why language, while important, really isn't the mark of
a good program or programmer.

-- bill

1. http://developers.facebook.com/thrift/