Comments (5)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 dan_darnell commented Permalink

I mainly live in the IBM i world. Wrapping Java Toolbox API's with EGL types (ala iJavaLib) is okay but an even greater degree of EGL integration is highly desirable. Compelling to me is the idea that with an open EGL the community could create abstractions for such things as data queues, data areas, validation lists, etc. and use the standard EGL IO statements with them. Annotations would provide the necessary metadata (keyed or non-keyed data queue, for example) in the implementation.

2 dan_darnell commented Permalink

An open EGL would provide the potential for creating abstractions for general business applications (financial, manufacturing, etc.). Thinking here along the lines of the Common Business Objects of IBM's San Francisco project.

3 Steiner commented Permalink

Open EGL is in itself very interesting.<div>&nbsp;</div> For example we would like to enrich the data items created by the data access application generator with information from our data dictionary (i.e. validator functions).<br /> Having hooks to add that kind of functionality would be great.<br /> And on top of that I still hope for EGL++.<br /> <img class="jive-emoticon" border="0" src="" alt=";-)" />

4 dlsanvil commented Permalink

From an application programmer perspective, if I could learn one language and be a C#, RPG, COBOL, C++, VB.NET, Java, PHP, javascript.... programmer, I am all for it! That's a no brainer, and I can't imagine any, but the most cultish, that would disagree with me!

5 S.Westerlinck commented Permalink

When I started being exposed to EGL two years ago - having a background of JEE/Open systems development -, I definitely liked the abstractions it gave compared to standard java. In fact, immediately seeing it as a DSL for business application development, hence complementary to Java. Furthermore, I also saw it as a candidate for providing that missing link in MDD (MDA) where it could fill the gap between your model and your target platform. Judging upon your question and your presentation of EGL open strategy, I believe it was the right way to view it at the time. However, my fellow Java adepts at the customer, still view it as a step backwards, instead of a step forward, and my guess is this mainly due to the tooling.<br /> As it did for other technologies, I strongly believe that an open EGL would provide the means to start getting tooling that more closely resembles that view of the language.<br /> Concretely at the customer it would have helped us with the following:<br /> <ul class="jive-dash"> <li>Provide a different implementation for the MQRecord type, perhaps based upon JMS for better integration with WebSphere, to include the standard routing component used internally. This way the developers could still keep using the EGL abstraction instead of using custom made functions</li> <li>Since they used it for both mainframe and unix development, a lot of common code contained "if systemtype equals" to provide proper behaviour depending on the target platform. This could have been abstracted out.</li> <li>Provide some extra annotation on SQLRecord to indicate potentially suitable for caching. Again using the same abstractions, data could be transparantly cached, by leaving it up to the compiler to decide for the particular target platform.</li> <li>...</li> </ul> <br /> Other uses I see are:<br /> <ul class="jive-dash"> <li>Make some abstractions based on design patterns, to help the compiler decide how to generate the most appropriate code in a given situation</li> <li>Define a stereotype XMLRecord, and having get understand XPath expressions</li> <li>...</li> </ul> <br /> So when will it be open, ;)) ? Or are there already some initiatives on this within IBM ?