GNU/EDMA Main Features
by David Martnez Oliveira
December 2002
------------------------------------------------------------
* INTRODUCTION
--------------
In this short paper I will try to describe the main features provided by GNU/EDMA, and how them relate to other nowadays available systems nowadays.

There are five key points in GNU/EDMA which will discuss in this text: component-based architecture, object oriented programming, reflection, extensibility and reuse. In the following section we will describe them.

* COMPONENTS
------------
GNU/EDMA is mainly a component system. You can think... "oh, my god!.. just another guy reinventing the wheel!". Well, that is true now, but this project began at the end of 1996 when no such a system existed for GNU/Linux... but that is another history.

Today you can choose among a lot of components models. You have the Bonobo model developed by the GNOME team, the Universal Component Model from the Qt people, and the XPCOM brought to us by the Mozilla comimunity to name a few.

The main and biggest difference among all these technologies and GNU/EDMA is that they are mostly based on the Microsoft COM model and the technologies built on top of it. So, XPCOM and UCM are basically COM, and Bonoboo can be seen as a higher level model closest to ActiveX or JavaBean models with a hard orientation to GUI applications.

GNU/EDMA is quite different to be considerated another thing.

First of all, all the COM based systems rely on a interface based model and a manual delegation model central to object. GNU/EDMA relies on classes like any other programming language and object delegation is completely transparent to the programmer.

In GNU/EDMA you just use the method or access the property you need without queries if an interface is there or not... of course you can write your program this way, but "that is not the unique way to" write your applications.

GNU/EDMA uses an approach similar to CORBA to define its classes/components. Each class in GNU/EDMA is composed by a interface definition file (IDF) and an implementation file (typically a shared library). The difference with CORBA is that interfaces are compiled at run-time, that is, you can see it like using CORBA DII all the time with less overhead, and, in general, a more simple interface. 

GNU/EDMA provides a very simple interface, no per-object-type factories, no interface query, no dependencies at source code level. As pointed above, you can work this way if you want, but you can also obey all these topics if you just want to write an application that do not requires those features.

See the tutorials at http://www.gnu.org/software/edma for examples on how to build and use GNU/EDMA components.

* OOP
-----
GNU/EDMA provides object oriented facilities in the component based environment we have just described. These facilities are integrated in a loosely coupled way that allows us to write true object oriented applications using a language like C.

Additionally GNU/EDMA provides all the classical OOP concepts in a full dynamic context, what this means is that you can use inheritance, override virtual methods, work with multimethods, etc... all at run-time. Hence, you can add new superclasses to your objects while your application is running, or override virtual methods changing objects behavior with time.

You can't do this with any other system without using tricky and obscure techniques. In addition to these dynamic features, all the OOP concepts mix in a seamless way with the component based infraestructures. So, components are classes and, for example, new components can be created by inheritance from existing ones, even if you don't have the source code from them, improving this way the reuse of components.

From a more technical point of view about OOP, GNU/EDMA allows programmers to choose their preferred flavors when building its applications. This way, programmer can choose among the well known superclass approach present in the most commonly used programming languages today (Java, C++, etc...), the INNER way ala Beta/gBeta or even the prototype based solutions provided by languages like Self.

The OOP features of GNU/EDMA are mostly oriented to improve the code reuse facilitating the mixin of existing components, classes or objects in a very easy way.

We must keep in mind that GNU/EDMA is not a programming language it is just a library that provides OOP features to applications. This fact has two consequences. First one is that you can use OOP with non OOP programming languages (like C), and in the second one your OO design gets independent of the underlying programming language syntax.

Of course, a native C++ program will be more efficient that its GNU/EDMA counterpart but reusing all your C++ code could become a hard task if you must to change your programming language, or even mix various programming languages in one application.

Finally, as pointer above, GNU/EDMA is enough flexible to provide various programming models. You can use, in some part of your program the Self way ("Parents are shared parts") in other the mostly complete Beta's INNER way, or the classical top-down class hierarchy of C++/Java/Smalltalk/Effiel, all of them at the same time, choosing the best fit solution in each part of your application.

* Reflection
------------
GNU/EDMA provides a quite complete reflection API that allows developers to virtually retrieve any information about each component in the system.

Reflection API in GNU/EDMA is two mainfold. In one hand, it is a required feature due to the dynamic nature of this system, in the sense that, if we want to exploit dynamically added features in our applications we need to know what they are in some way..

In the other hand, the GNU/EDMA reflection API is a key feature to build specific development tools for this system.

* Extensibility
---------------
From the beginning, GNU/EDMA was conceived as an evolving system, in the sense that is could embrance current and new technologies appearing in the future, and that new features could be added to the main core in the easiest possible way.

Extensibility in GNU/EDMA is achieved through three main subsystems embedded in the core of the system. 

First one is named IngrIDF and it is a set of primitives to process classes/components interfaces. IngrIDF, allows to write your own IDF (Interface Definition Files) parsers and it should also allow to write parsers for processing other systems interfaces, as for example, CORBA IDL files, or even Java bytecodes.

Second one is named SIU and it is a generic proxy system that allows developers to customize the basic GNU/EDMA primitives, in order to interface GNU/EDMA with other systems and to provide further features not envisioned at the first time. For example, the Perl interface in progress uses SIU Proxies to forward GNU/EDMA applications calls to the Perl interpreted. Somo Aspect Oriented Programming experiments are in progress using this subsystem.

Finally, the EMI subsystem provides an interface to allow developers deal with internal problems in the core system. At the moment this is the less mature of all this subsystem and it just allow to process the CLASS_NOT_FOUND exception, that is, we can write code to try to find a required class (for example through the net).

All this three subsystems are built on top of the GNU/EDMA platform, that is, any IngrIDF parser, SIU proxy or EMI handler are just GNU/EDMA classes with special attributes.

Compare the facilities provided by these subsystem with other component models or even programming languages. 

IngriDF allows you to customize your interface definition files and process them at run-time, that is the equivalent process to compile the interface to build stub and skeletons in systems like CORBA. Doing this in other systems may be quite complex or even impossible without changing its internal behavior.

SIU Proxies trivializes the adaptor and proxy design patterns, and provides a uniform interface for interfacing other system with GNU/EDMA. At the same time it provides a simple way to extend your GNU/EDMA primitives and to apply them individually to specific objects.

The function of EMI handlers its more common in nowadays system. For example, you can get a quiet similar behavior with Java Class Loaders or external services provided by other component systems (the CORBA interface repository, for example).

* REUSE
-------
Reuse is one of the objectives we are trying to achieve with GNU/EDMA and it is one of the main reasons to create this system.

GNU/EDMA's component based model and object orientation directly promotes code reuse but you can achieve higher reuse degrees.

GNU/EDMA is written in C programming language, and datatype and operating system adaptation features are built-in in the system. This means that you can reuse most of your code even between platforms with little or no modification at all. In the other hand, using C programming language allows developers to interface GNU/EDMA with virtually any other system and, this way, reuse any piece of code available.

The classes/components you write can be registered in a whole system way, what makes them available to all the applications in the system. From this point of view, GNU/EDMA is like a OO library management system.

An important difference between GNU/EDMA and other systems is that GNU/EDMA extends object orientation to the components, allowing this way build new components that inherints from existing one without writting complex delegation code to mix the components.

Finally, GNU/EDMA applications and components can be built without any dependency at the source code level, that is, you do not need any special include file for doing that. The main drawback of this approach is that compiler can detect some error at compile-time and you must do extra checking at run-time. Note that this is only necessary if you want a fully dynamic, lossely coupled application.

* CONCLUSIONS
-------------
GNU/EDMA is just another try to reinvent the whell but with some improvements that can make more easy build and tune your applications.

Most of the functions commonly provided by similar systems can be achieved in a more easy and comprehensive way, and with less system requirements.

At the same time, it is a framework for general software engineering research 
