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



You do that by creating UI-independent server logic and then adding the
appropriate intrefaces, be it programmatic such as web services or
user-centric, such as browsers.

Agreed.

The last thing I see a need for is an RPG-specific GUI extension.

I can understand that statement based on your involvement in Java
environments. You have found excellent efficiencies in the Java/EGL to RPG
environments. I think the challenge is for others to find those same
efficiencies without your many years of knowledge.

In fact, aren't you suggesting using a rich client framework that runs on
the desktop?

Yes, I believe that to be an accurate statement as long as the rich client
is only a render engine and doesn't need to be updated when applications are
updated. Basically a GUI Client Access.

If so, how do you export that to, say, a Macintosh? Or a PDA? Or a
handheld bar scanner? Or a GPS device? Or a DNLA-enabled home network?

This is where I think IBM's Java knowledge could shine greatly. I would
rely on IBM to create a platform independent proprietary rich client in
Java. Note that this rich client would be VERY small in file size and CPU
consumption because all it knows how to do is connect with a server and
render a data stream sent to it.

I gain an efficiency here because I don't have to adhere to technologies
that IBM has zero control over, and instead can install the proprietary
client on Macs, PDA's, handheld scanners, etc, and if the IBM client can't
be installed, then THAT is when I go outside of the proprietary/efficient
box and build something according to the spec the device supports. What IBM
is now recommending is that we immediately and entirely go out of the IBM
proprietary/efficient box with EGL by, for the most part, developing most
everything in the browser.

Now, the browser could be used as a delivery mechanism for this IBM
proprietary client just like how you can easily load Adobe Flash/Flex with a
click of a button in FF.

I don't understand your point here. If they can write it faster and it
runs better in EGL, then yes they will. But then again, that's what the SQL
folks have been pushing for a long time with their "no native I/O"
silliness. I'll continue to push against that SQL-only just like I will
push against rip and replace with EGL, and I'm confident that most companies
will realize the folly of either approach.

I think we will have to wait for a couple years to see what the longterm EGL
lifecycle development holds for efficiencies. You (and the other EGL
supporters) have shown us how to create new applications quickly and easily,
but it will be interesting to see how easy that application is to maintain
over the next 5 to 8 years. For example, with the EGL team be careful about
backwards compatibility of the language or will they take a Microsoft
approach?

On the point of native I/O, I had a customer ask me a few years ago "we are
going to migrate all our I/O to SQL vs. CHAIN/READ/SETLL/etc, do you see any
drawbacks to that?". I asked them what they gained from going the "SQL
only" route and a few features were named (i.e. ability to do adhoc sorting,
etc). But what they didn't realize is they were throwing out a VERY
efficient DB communication mechanism for a syntactically less efficient one
simply because of a handful of important feature sets when both could
co-exist. Of course I recommended they use SQL where it made sense and then
use native I/O to keep their existing efficiencies. But the fact of the
matter is many shops are all about black and white approaches to
modernization, and that is why I think if EGL is introduced into RPG shops
that it will eventually lead to EGL being used for business logic and data
I/O. We have reached an age where programmers need to also have knowledge
of when and when not to adopt technology. Or maybe better stated, how much
of a technology to adopt.

What do you base that on? The incredible uptake of RPG ILE? <grin> Aaron,
I'd have to say that the overwhelming historical evidence on the platform
suggests that RPG programmers don't jump willy-nilly to a new technology.

I would guess the "young punk" of the group will be the first to pick it up
and probably implement good looking EGL apps that wont scale well. Then the
RPG programmers will be struggling to state that RPG should still be in the
mix. The RPG programmers would be declaring this to an IT manager that
hasn't written code at all, or hasn't done so in a long time.

Aaron Bartell
http://mowyourlawn.com

As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.