Re: Impressions of EGL - Part Duex

Aaron Bartell skrev den 26-05-2008 04:37:

We are reaching a point in the IT dept infrastructure where "framework
evaluator/builder" is actually going to be a job description. I predict

It just shows that the right kind of glue between modules has not been found yet. Instead of carving everything from hardwood we need something that allows us to work with Meccano or Lego Bricks (just to twist a metaphor).

What needs to be done to do this I don't know, but it might be putting components in real bricks. Lets see what time will bring.

So now that we have established my preference to build a system whose
controller, business logic and DB I/O code is all written in RPG, we have
one last point - what does the end user interface look like and how is it
built?

When reading your post my initial thought was "Why can't RPG be put in the browser?" and if a tiny RPG subset could be running in the same way that Flash do today (with an installation procedure similar to Flash), with a complete access to the web page in the same way as javascript, would that not be a good way to allow RPG programmers to work on the whole she-bang?

So what I thought of was basically a "FlashRPG" thing in the page, after which you can put RPG snippets to the browser and let it work with it.

I know that this would be "yet another web famework balblabla", but this one I think would actually be without the steep learning curve plagueing other solutions

I/O language. The most important thing about the framework is that we
needed the client piece to completely draw screens based on meta-data
because we could only install one version of the software ever (I wont
digress into that subject). What that meant was I had to develop the Java

Lovely. Could you ship java classes to the printer?

You might also find the Jetty configuration classes interesting - they basically allow you to provide java snippets as XML, which is both simple and powerful.

Sorry for the long and probably loose-ended response. I hope to put
together an article series on just this topic full of actual code examples
showing implementations (I have one set partially developed for iSeries
Network that I just need to round off) and describe the shortcomings of the
different approaches.

I think it is great to hear what others are doing as it may inspire to do stuff or avoid some other stuff, so no complaints from here.

Additionally I think that this list stands out simply because people are more experienced and KNOW what it means to support code for decades. This is a quality that 90% of the software world do not have - additionally you also know that "this is old so we need to replace it" does not work when the software actually still performs, and that it actually matters that software is fast.

We are entering a new age - the CPU's do not get faster any more (not by much) but instead get more cores. So it is no longer an option just to buy a new machine next year...