× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



From: Aaron Bartell

My actual hands-on experience with EGL is limited, though I can base most
of
my comments without even having to touch it. I don't want to get into a
barking match about whether or not Java is complex for RPG developers, but
what I will say is that in the end you are still required to run Java
which
inherrently means you need to run an app server. My problem is the
software
stack involved in the EGL model vs. what IBM has delivered in the past.

This is a pretty poor argument, Aaron. An app server is no more work than
Apache. Are you now telling us that Tomcat is too hard for RPG programmers?
Because if it is, then thousands of script kiddies have better programming
skills than RPG programmers.

Sorry, Aaron, but you're going to have to lose your aversion to anything
that even looks like Java if you're going to have a credible argument in
this space.


You can use JSP Model 2 and write your own plumbing

I would consider this an acceptable model, but in the same breath we
shouldn't been writing plumbing code - we should be getting a tool from
IBM
that does it for us in a software stack that doesn't require application
servers.

I think I said that. I said that JSP Model 2 is akin to DSM, which I think
you would agree is more work than most RPG application programmers should be
doing. It's crucial for some specific requirements, and otherwise you
should use a higher level of abstraction.


You can create a web page that shows a list of orders in about a minute.

This is cool, IBM is getting closer to Visual Studio ease of use. The
problem with this is that the code usually isn't enterprise ready (DB conn
pooling and stuff like that). Some apps on the iSeries don't need to be
enterprise level, but I would say that MOST do.

Again, your lack of knowledge is showing. This stuff is written from the
ground up to support not only connection pooling, but JNDI and J2C and all
that other good stuff. That's part of the beauty of the Java stack; all of
the enterprise level functions are standardized, unlike just about any other
stack.


All without a single line of Java code.

I read your article in IBMsystemsmag.com just so I could debate with you
accordingly :-) In that article you WERE writing plumbing code to make
your
app work how you had hoped. I believe it was more on the JavaScript side
and NOT Java, but in the end it isn't this panacea you keep declaring it
is.

Which article? From my April article
(http://www.ibmsystemsmag.com/i5/april07/developer/12353p5.aspx):

"More importantly, EGL does all the plumbing for you. With just a few simple
definitions, you can identify an RPG program to call. And then a single line
of EGL code calls that RPG program directly, passing it the data structure
you defined. The called program fills the data structure with data and
returns it to the EGL program, where you would then add that data structure
to an array and go back and get another line of data, much as you would for
a subfile."

Please, Aaron, show me the code you're talking about. The only code I wrote
was calling an RPG program in a loop to fill an array. If that's too much
plumbing for you, then you're really fighting a losing battle here.


I don't get it. If the issue is ease of development, EGL is the answer.
What are you waiting for?

I get the feeling you really like this tool IBM has come out with even
though we both know they could have done it completely in the native
RPG/C/C++ software stack. That's my big issue I guess. Sure this EGL
stuff
looks like the next great thing, but I keep getting hung up on wanting to
pursue IBM for what they can and SHOULD be developing for the iSeries. I
agree I have to be careful on that hang-up because some progress is better
than none. My clash with you is that you are putting SO much emphasis on
this as the golden ticket when in my mind you haven't been as objective as
the Joe Pluta I know. Is that a fair statement?

You're talking about objective??? When your primary argument has been "it
has Java in it, so it must be bad!" Well, pleased to meet you Mr. Pot, I'm
Mr. Kettle! <grin>

Seriously, Aaron, your almost pathological hatred of Java is blinding you to
the best set of solutions on the planet. No, I don't think this could be
done using RPG/C/C++ (C? C++? Who programs in those these days?). They
would have had to rewrite all of the J2EE stuff such as security and
connection pooling, which would have been a horrendous waste of resources.
They would have had to reinvent JavaServer Faces in RPG, which neither
CGI-DEV or RPGSp really supports (you have to really look into the JSF
support for both client-side and server-side to see what it does).

And because they didn't, the team has been able to spend a substantial
amount of resources making some changes to the standard J2EE in order to
support us lowly RPG programmers (things like persistent sessions, which
aren't inherent to the stateless Web world).

More importantly, Aaron, by leveraging a global standard like J2EE, the EGL
team has ensured that as new standards are added to the Java platform that
they will be available to the EGL programmer, rather than constantly playing
catchup and having to rewrite those standards in RPG (or C/C++ <shudder>).
This is much the same way that WDSC leverages Eclipse, giving us a state of
the art IDE rather than trying to figure out how to add wizards to SEU.

I am advocating EGL with the same zeal that I have had for WDSC, and I'm
getting the exact same kind of pushback.

Here's the 64,000 dollar question: was I right about WDSC or not?

Joe


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.