Tuesday, August 7, 2012

What's cooking in the EDT kitchen? - August 7

I'm happy to say that EDT 0.8.1 was released a few days after my last post.

The schedule and content for EDT 0.8.2 have been posted on the EDT wiki. The two main themes for the release are Extensibility and Language. The Extensibility effort's aim is to make a pluggable framework for compilers and generators, which our code will then use. The goal for the Language theme is to implement the core elements of EGL that we haven't implemented yet.

During the last two weeks we changed version control systems, from CVS to Git. This has slowed us down a little, but we're getting used to Git. (By the way, if you're interested in contributing to EDT, read our Developer's Guide to Getting Started on EDT.)

Here are the other things we've been doing:

  • Making validation of EGL source code extensible.
  • Making it possible to add new types.
Other Matt


  1. Hi Matt,

    Ben posted in reply to a comment with some additional information about the goals of this next release. They make sense to me but when I looked at the schedule and saw a mid-January 2013 release date I groaned.

    If things like HTML5 support are not even remotely on the table until after 1.0 can you help us understand -- in very broad terms and without making any commitments -- where ExGL (that's what I call EGL now ... "Extensible Generation Language") goes from 0.8.2 and when that 1.0 release might happen?

    There is still a little nagging doubt in my mind about whether ExGL is even intended to be a real-world language. I could see this being essentially an engineering exercise on the part of the designers. If ExGL is ever going to get legs and make inroads as a language for the web used by developers of all stripes then releases are going to have to deliver on BOTH engineering goals (compiler and generator completion) and developer needs (things like HTML5). So far, releases have done this brilliantly (witness the Dojo Mobile support and IBM i extensions along with all the core stuff) but 0.8.2 departs from this model. When coupled with the time frame for the 0.8.2 release and the lack of an overall release schedule the change in approach represented by this release worries me.

    Is there any additional information you can pass on regarding the overall project timeline? Thoughts on whether or not ExGL is intended for real-world use and who the target developer audience is for the project/product?



  2. Hi Dan,

    I agree with you that we need more language enhancements like HTML5 support. But, until now, all of our releases have focused on language and IDE enhancements. We decided that we couldn't delay the compiler and generator extensibility changes any longer. It's a huge task: every part of EDT, except the runtimes, are affected in some way. As you saw on the wiki page, the result is a longer than normal schedule for 0.8.2.

    Extensibility is one of the two reasons for EDT's existence (the other is to provide an open-source EGL development environment). There are already many free/open IDEs, for many languages. Extensibility will set EDT apart and help attract people to EGL. We'll have a larger user base than a "normal" EGL IDE would have, and that will pay dividends in all kinds of ways.

    We realize that the extensibility work isn't exciting to many of our current users, but it's fundamental to the project's success, so it must be included in version 1.0. Now is the time to do it.

    That being said, if someone in the EDT community wants to contribute a language enhancement (e.g. HTML5 support), we'll certainly consider it for 0.8.2.

    As for the overall project timeline, we may or may not have more 0.8.x releases. It depends on how many features we can't live without and how many bugs need to be fixed. When we reach version 0.9, we'll freeze our APIs and finish the specification and implementation of the language. We don't plan to have any 0.9.x releases. We think version 1.0 needs to be very solid, so any changes from 0.9 to 1.0 will be specifically related to quality (bug fixes, API changes, and necessary enhancements).

    This plan is by no means set in stone!

    If there are no more 0.8.x releases, and versions 0.9 and 1.0 take about four months, then version 1.0 will be finished in August or September next year.


  3. Thanks, Matt. I'm going to hold you to that August 2013 date. (Just kidding!)

    I do very much appreciate the additional perspective. Knowing more about the overall plan helps on this end as we keep a watchful eye on the project and where it is going.

    I get the impression that this is virtually 100% an IBM/Rational effort. It would be very helpful in moving the project forward if one of the larger non-IBM players in the EGL space could put some resources into the project. The extensibility of EGL coupled with the basic philosophy of an open-source effort cries out for involvement from outside of the core (paid) team of the project originator.


  4. You're welcome, Dan. One day soon I'll write an EDT Roadmap page for the wiki.

    It would be great if more from people outside of IBM got involved in the development of the project. We won't turn anyone away if they have something to offer. How about you?


  5. It's kind of tough as a one-man show to keep my head above water financially and also do work that isn't billable.

    I would love to be the guy that contributes the Eclipse view that shows at a glance the generation settings for a selected project, package, or part. The only thing holding me back is the fact that I have no idea how to code such a thing. :) Seriously though, I have looked into doing this but don't get far before other demands on my time take me away from the effort. As time allows -- and if the project team doesn't beat me to the deliverable -- I am going to keep after it.

    I have also been spending some time toying with the work that Chris Laffra did to bring enhanced functionality to EGL CE (2D drawing, browser storage, etc.) -- making it work for EDT. Some of this is HTML5 stuff and, if I make any significant progress, I will share it.


  6. Dan,

    Regarding existing EGL code written to support HTML5, the following Developer Works article may be useful - https://www.ibm.com/developerworks/mydeveloperworks/blogs/3e2b35ae-d3b1-4008-adee-2b31d4be5c92/entry/previewing_two_html5_features_for_use_in_egl_applications17?lang=en


  7. That is helpful. I had forgotten about the HTML5 preview for EGL/RBD. I've written quite a few widgets for my own use but something that trips me up when I think about creating widgets suitable for inclusion in an effort like EDT is my concern that there are certain rules that should be followed of which I am not aware. For example, when I look at Dojo widgets and others written by IBM (like those in the HTML5 preview) I see function calls on "eze$$DOMElement" and "egl" used extensively in the hand-written JavaScript code use to implement widgets and classes. I have no idea what functions these objects provide outside of what I see used when I poke around IBM-created widgets. And as I said, I see calls to functions and properties set that seem like they are probably fundamentally important.

    Is there any documentation that outlines the expectations on a widget implementation so that it will play nice in the EDT world? Any documentation for the "eze$$xxxxxx" and other apparently internal objects that a widget developer should/could/might use?


  8. Great piece of work. Hope that you will go ahead to create creative and outstanding post like that.
    Team cooking
    Motivational speakers