EGL and i

RE: Welcome to EGL and i

JoePluta — Fri, 20 Jun 2008 13:46:42 GMT

Thanks, Kurt!

This is a very long laundry list and is in effect a sort of design specification for a GUI tool. The primary issue here is that the interface is server-centric; the server runs the show. When I wrote my e-Deployment book back in 2000 I outlined exactly this architecture: JSP pages replaced 5250 screens. I call this "server/client" as opposed to "client/server" and your associate seems to understand the difference.

EGL is not a server/client model. Although it can be used that way, as can JSP, bending the browser to act as a "dumb tube" akin to a 5250 is neither simple nor 100% successful. Certain issues like closing the browser or cross-browser compatibility tend to come into play. My PSC iQ product comes about as close as anything available on the market, and the HATS/Webfacing technology is very similar.

But no, I don't think that there is an out-of-the-box match between what this person is asking for and what EGL provides.

RE: Welcome to EGL and i

KurtRump — Thu, 19 Jun 2008 14:35:44 GMT

Following are excerpts from the e-mail I referenced regarding a GUI interface for RPG. When I spoke to the author, he described himself not as a computer scientist or programmer, but as a business man who learned a simple programming language (RPG) and began writing applications to meet the needs of a school district. You'll see in his comments the level of frustration that has surfaced with regard to the complexities of building a Web interface. He goes on to propose a possible architecture from his point of view. And by the way, his reference to both Mac and PC users is intended to raise awareness to the fact that many of the tools available (e.g. HATS) don't list Mac browsers among those that are supported. Here you go...

"This is a big problem for us and other school districts that I know about that are using the AS/400.
We really need to be able to easily talk to our teachers, students and parents and we cannot use
5250 emulation to do that. Many districts are plagued with having both Windows and Mac computers
that they have to support, so web applications need to be browser independent.

Things that we need from our end to support this environment.
1. When I do a wrkactjob, I need to be able to see who is on the computer and what it is they are running. If we try and use the traditional HTTP jobs that the internet runs, we just get hits to our server. That is really hard to work with if there is a problem. That is also a performance hit for the user when programs and files continually need to be opened every time data is needed. All of our work is OLTP. We don't run a public web site from our AS/400.

2. I have avoided using RPG IV as much as possible as it was not written for RPG programmers. It has some nice features for some things and I have used it where needed. I recognize that RPG/400 is no longer being enhanced and I expect that any GUI interface will only be offered in the current version of RPG. If it is easy to use, that won't be a problem. I expect all the 'character to data' conversion that takes place in the 5250 world to also work in the GUI world. Everything that I have seen of the "Open" solutions is a real pain when it comes to data conversions. That is why I expressed the implementation as EXFMT WEBPAGE. That should explain it.

The browser based platform on which the applications are being presented needs to be smart enough to know when the user just clicks on the back button or the red X, to close the window and not just drop the connection. The environment that I am looking for is NOT one where a user is doing their normal jumping around web sites. When they jump into this interactive mode, they need to be under program control so they cannot have access to these other "Web" features, until they exit the application they are in. I don't really want to deal with session cookies, etc. I don't do that in the 5250 environment and I don't want to do that in a Browser environment. To me this is just a screen that I am using to communicate with the user. I want the ability to make the user interface more like a Windows or Mac user program, and not have users jumping around to other things.

Please start with i5/OS and work towards using the browser as a screen and do not work at coming from the Internet and try to get the RPG program to work like PHP or some other scripting language talking to the HTTP server. That is a long way from where I need to be at this point. For those types of activities, I can use PHP or the XML features in RPG for web services. That whole model is entirely too complicated for doing OLTP and too slow to run and or develop applications in.

I hope that this makes it easier to implement. Some kind of a "plug-in" that takes over the browser for this kind of communication would be just fine. This could be checked each time the connection is established to see if it is current. If not, the latest plug-in could be sent to that browser before the application loads. That should be something totally transparent to the application running on the AS/400. What I cannot do is have someone loading or maintaining programs on computers that will be communicating with the AS/400. I have over 60,000 students, thousands of teachers, and a lot of parents. None of them would spend a lot of time on the AS/400, but when they do, the user interface needs to be fast, simple to use, capable of supporting e-mail and pictures, and have the ability to print reports on their local printers. They should also have the ability to browse and attach files, as needed by the specific application. These are simple things that people are used to doing in their browser. If this is a fully integrated function that can be done by running an RPG program on an AS/400 then we have a good connection to our customers.

DDS has a lot of things that our current 5250 emulator does not support, such as mouse clicks, drop down lists, etc. I don't really expect that I would use a green screen to design a browser interface. If I end up using a PC to create the interface, it needs to be very close to what I have used DDS to create for the green screen. I use the PC to create the interface, create an object in a library that will then be available when I compile the RPG program. When I do the EXFMT WEBPAGE, the program runs and displays the screen in my browser. I recognize that is probably the sticking point in the development, because there is no clear way to do that. I have no idea as to how the 5250 environment works currently with my PC and I know even less about the browser and how it works, but somehow the connection needs to be made. I know that the browser is designed to work with the HTTP server, but either the connection needs to be made behind that on the AS/400, or this plug-in needs to be able to get the browser to connect to the 5250 data stream or some other xxx data stream that would be coming out of the AS/400 so that we get this connection made."

RE: Welcome to EGL and i

JoePluta — Wed, 18 Jun 2008 17:01:16 GMT

Yes, I think I would. EGL is as close to a native GUI as I want anything to be, actually. While 5250 was a great idea for its time, that was because there really was no other standard out there. The 5250 datastream filled the place of HTML and CSS and all that other good stuff we're using today - if you think about it the 5250 display was in some ways a browser for character data.

Some people are asking for a GUI enhancement to the RPG language - a new datastream for the new millenium, I guess you could call it. But the problem I see with that is that no matter how good it is, it will always be behind the curve. The pace of technology is such that frameworks like Dojo and YUI and GWTx are proliferating and expanding faster than any one company could match. So the best answer is not to emulate, but to integrate. In OO terms, provide an Adapter - use a simple business-oriented syntax to allow programmers to access the complex capabilities of these new frameworks.

That's where EGL is going to really shine, in my opinion. By abstracting the concept of UI, it avoids getting locked into any one technology, and instead allows developers to use the toolset which fits best. The Rich Web Services stuff that's coming out soon is really going to raise the bar on what business programmers can do.

Because the native GUI of the i shouldn't be any one technology - it should be all of them.

And please, send me the response. I'd love to see it and I'd love to see if I can indeed address this entire architecture issue as the blog progresses.

RE: Welcome to EGL and i

KurtRump — Wed, 18 Jun 2008 15:09:06 GMT

I have seen numerous posts in other forums where traditional i developers have pleaded for a native GUI. Your description of EGL as "the spiritual successor to the 5250" that is "as easy, if not easier, to use than the old green screen SDA" suggests to me that EGL might be the closest thing there is to a native GUI. Would you agree?

I am not an application developer, but I have the opportunity to speak to many of them. One of them took the time to send me an e-mail which documented his thoughts and concerns about current GUI approaches available to the RPG developer. If you're interested, I could forward it to you. Meanwhile, if EGL is the answer, I'd like to have a simple and compelling way to convey this to the i community. Perhaps you could use your blog to help flesh out the story.