[rtg] Traffic is wrapping

[Leech, Jonathan]

Bill,

Thanks for your response.

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. 

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.

-Jonathan

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

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

On Tue, Apr 08, 2008 at 10:38:41AM -0600, Leech, Jonathan wrote:
> My first thought was to improve and contribute to the JRTG codebase, 
> but with no disrepect to the original developers and design, that just

> wasn't feasible.

i understand that position.

> Second, I would like to point out that in the example from my code 
> there is no Java or OOP, other than Java String comparisons. And that 
> particular example is of features I made for JRTG that RTG just 
> doesn't have, the ability to change its configuration on the fly, and 
> to send the polling results to multiple delegates.

i don't want to get into a language war[1], but the line i quoted is
enough logic in one line to hurt my brain.

it's funny that for all the OOP and C++-like features java provides,
it's still just string comparisons to determine if it's time to
instantiate something new.

defining multiple database servers was one thing i was adding to the
lex/yacc code, first as a fallback, later to point hosts or OIDs

> I don't have any experience with Ruby, as I know it best, my 
> colleagues now it best, there are a tremendous amount of libraries 
> written for it (including SNMP4J which is the basis for JRTG), and is 
> the most stable platform around for writing server-side code. Java's 
> concurrent threading packages make writing multithreaded programs like

> JRTG a breeze.

java may make writing programs like that a breeze, but reading them sure
is a different story.


but as i said, i don't know java. if i did, i might have done my near
rewrite in java.  if php had anything close to real thread support, i'd
have considered rewriting the whole thing in php. it doesn't so i
didn't.

i didn't know ruby at the time (and still am just taking baby steps). i
merely was musing that ruby has a nice balance of OOP, thread
primitives/harvesting/etc, and ease of entry over C that could help
attract more developers to it.

i guess the point i was trying to make is that, code-wise, i can see the
original rtg code in JRTG... it just happens to be surrounded by 3x-5x
times more code to support the magic that all the java classes, DB
agnostic layer, thread libraries, etc. that's neither here nor there.
it's well documented in javadoc. it's a quick read to get through all
the com.virtella.poller package. i'm not knocking it.

do you have any intention on updating/maintaining/supporting the code as
a public project or is what's on the sourceforge site just a onetime
import?

-- bill

1. http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html