EDMA

EDMA TechNotes

In this section we provide some more technical information to help the reader to get a clearer idea of what EDMA is and how it works. We hope that this page will disappear in the future, replaced by more suitable tutorials on EDMA programming.

Main Architecture

EDMA consists of three main elements: the class register, the class implementations and the class interfaces.

The class register is a simple text file that contains the information about all the classes available in your system. Any class that appears in this register can be used by any application.

Each class is formed by two files: an implementation file that contains the code of the class, the method that this class define, and an interface file that contains a text definition of the properties and methods defined by the class. The interface file is like .h files for C/C++ applications: it defines the variables and methods that the class uses. Actually it only defines the symbolic information required by the system for building the data block for an object of that class, and for linking the implementation of the class.

A first difference between EDMA and other systems is that there is no interface compiler. The classes' interfaces are processed at run-time and translated to an internal representation hidden to the outer world.

So to build an EDMA class you must provide an implementation for this class, the code associated to any method that the class defines, and an interface file that contains all the properties (variables) and methods (functions) that the class defines. And you must add the class to the register in order to make the new class available.

All the work is carried out by a single library called edma32.dll that you must to link to your applications in order to use the primitives that it defines.

Programming Interface

Since all operations are done at run-time, no language binding is available. EDMA has been developed to work in the C language, and for other languages it is necessary to develop wrapper code. The next version will provide a CORBA-like dynamic invocation interface to allow the use of EDMA from languages that don't support variable parameter number functions.

If you don't want to use EDMA as an object-oriented system, you only need to know six primitives: NewObj, FreeObj, WProp3, RProp3, Met3 and Met3S.

The first two allow you to create and destroy instances of some class, objects. If you aren't interested in object programming, you can consider the NewObj primitive a function that allocates some memory for storing data and brings to your application some code stored in a library, loading it if necessary. You don't need to tell the linker the libraries that you want to use: EDMA manages this.

The WProp3 and RProp3 primitives allow you to access the data block associated with the object. The first allows you to write to it and the second allows you to read from it.

The Met3 and Met3S primitives allow you to execute code, some function defined in the library or class implementation. Met3S invokes a method with signature and is provided for defining polymorphic behaviors; this will not interest non-object-oriented programmers.

With these six primitives you can load libraries and use the code in them easily. You can make changes in the libraries without recompiling either the libraries (components/classes) that the application uses or the application itself.

You can update your applications by distributing new versions of individual components. If you use the reflection API of EDMA, you can look for new classes and add new functionalities to your application as add plug-ins, without any additional work.

We provide a simple example of how to invoke these primitives, but if you want to use EDMA you must to take a look at the examples in the distribution and read the documentation (if you know Spanish). This is an example of pseudocode for adding plug-ins to an application using EDMA.

// Get a Plug-in name from some place. This must be a string

// The NewObj primitive expects to get a string as parameter

// for example NewObj("QuickTimeView",NULL);

OBJID plug_in;

PLUG_IN_STATUS status_var;

plug_in=NewObj(plug_in_name,NULL);

// We tell the plug-in that will be embedded in out main window

WProp3 (plug_in,"Embeded",1);

// We read the status of it

Rprop3(plug_in,"Status",&status_var);

// We run the plugin

Met3(plug_in,"Run");

// We Free the plug-in

FreeObj(plug_in);

Note that properties and methods are refered to by strings. Their names are defined in the interface file associated with the plug-in.

Object Oriented Facilities

Now we look at the object-oriented facilities in EDMA. This is a difficult topic, so we only introduce some of the facilities. First we introduce some of the opportunities that dynamic object oriented facilities offer the programmer.

You can add new subclasses and superclasses to an object at any time, which will change its behavior.

This allows to the programmer to build an object and specialize it later, when additional information is available. For example, you can create an object of class IMAGE and add a graphical decoder class when the user clicks on a button, changing the object of class IMAGE into an object of class IMAGE_JPG, IMAGE_PNG, ...

Changing superclasses in run-time is also allowed. For example, suppose you have some set of classes for image filtering: SHARPEN, BLUR, EMBOSS, etc. These classes are linear filters that inherit from a base class LINEAR_FILTER. When you create an object of one of these classes, EDMA will link the LINEAR_FILER class code to the object. The application may then look for MMX extensions on your machine, so you can add the normal LINEAR_FILTER class or a LINEAR_FILTER_MMX class instead.

You can override any virtual method on an object in order to exploit dynamical inheritance

This allows you to override a virtual method at any time, so you can get dynamic polymorphism. That is, the object can change its behavior with time. For example, imagine that you are developing a war game. You have a class that holds the AI of the machine player and in the main loop of the application you execute some method. You can develop "strategy" classes that are loaded by the computer player at run-time, overriding this method. An AI engine can determine which strategy to use at each moment, load the desired strategy class, and override the main loop method. The main loop method does not need to change.

EDMA class paths allow you to walk through the class diagram.

EDMA uses class paths to allow the programmer to move around the class diagram. A class path is a filesystem-like path. Any classes added to an object are treated as directories that contain properties, methods and other subdirectories. To access an item in these directories you need to indicate the relative path from your current location. There is a first implementation for a one-level interface of this that allows the programmer to access items by name without the full relative path, as in C++ or Java. The drawback of this solution is that name resolution is a bit slower than indicating the class path, because there are more comparisons to do.

EDMA supports on-demand inheritance.

To add new classes to an object, you must invoke special EDMA primitives that are a bit complex to use because of their flexibility. The on-demand inheritance facility allows the programmer to suppose that some class diagram is associated to the object, and invoke primitives on it as if this diagram really exists. EDMA builds the diagram at run-time, when needed. The programmer needs to specify a class path, that is a filesystem-like path with name of the classes related. For example, if you want to add the BLUR subclass to a LINEAR_FILTER object you can invoke any basic primitive (WProp3, RProp3, Met3,..) on it with the associated class path BLUR/propname or BLUR/metname. This will automatically add the BLUR subclass to the LINEAR_FILTER class.

This interface will probably change in the next version, because it is not clear whether you are adding a subclass or a superclass to the object. We may use the < and > characters to indicate whether we are going up or down in the class diagram; we hope to get this change working soon and to maintain compatibility with the / interface.

There are other object-related facilities in EDMA which we will not dicuss here. We hope to write a tutorial about these soon.

Extension Systems

EDMA offers three main extension subsystems:

The IngrIDF subsystem allows you to add new parser interfaces for interface definition files. EDMA supports a native interface format named EDMAIDF, but in order to make EDMA work well with other systems we add the facility to define class interface files in other formats. The IngrIDF system provides a set of EDMA primitives for developing interface parsers. The IngrIDF parsers are EDMA classes that are used by EDMA itself in order to access class interface information in formats other than EDMAIDF.

The most complex example available of an IngrIDF parser is the JAVA_IDF class. This EDMA class is a parser for retrieving class interface information from Java bytecode and is part of the JANE system, a set of EDMA classes that allows you to use Java classes as if they were EDMA classes.

The interface format used for a class is defined in the class register, in the field IDFParser. Most classes use EDMAIDF, that is, the register entry for this classes is IDFParser=EDMAIDF, but you can develop new parsers as EDMA classes and indicate the class name in the IDFParser field. For example, a registered Java class on the system will show this entry: IDFParser=JAVA_IDF. This means that when EDMA needs to get interface information for that class it will use an instance of the class JAVA_IDF instead of the native code.

The IDF parsers are marked in the class register too. A field named IsIDFParser indicates that the class is an IDF parser if it contains the value 1, or not if it contains value 0 or is omitted.

Another important extension system in EDMA is the SIU subsystem. This allows you to use other implementation formats that dynamically link libraries. The SIU subsystem is based on PROXY objects; these are objects that represent an object outside of EDMA. For example, for a class implemented using Java bytecode, we must build a PROXY class that talks to the Java Virtual Machine to communicate with the real Java object, that takes the EDMA primitives and translates them into Java Virtual Machine calls.

There are two ways to use SIU: direct access and blind interface access. Direct access is used when the PROXY class for accessing some object is defined in the class register. For such a class, we will have an entry like SIUPROXY=MyProxyClass. When an object of a class declared with the direct access is created, EDMA creates an object of the related PROXY class, and redirects all calls to this object instead to the real object. Blind interface access allows to the programmer to select which PROXY to use for an object when it is created. To do that, you must specify the classname with the PROXY class name to use between parentheses. For example NewObj("(JAVAPROXY)MyFrame",NULL); will create a JAVAPROXY (this is a class name) object, and all the calls to the object returned will be redirected to this object, which will talk to the Java Virtual Machine.

The final extension system in EDMA is the EMI subsystem. This subsystem allows classes to be registered to manage internal EDMA exceptions. This is the least developed extension system and the only exception that it can manage is the so-called "CLASS NOT FOUND" exception. When a program tries to create an object of a class that isn't registered in the system, a CLASS NOT FOUND exception is launched. If a class is registered for managing this, EDMA will yield control to an instance of it and will let it try to resolve the problem.

We have developed a simple system that allows classes to be downloaded over a network connection and registered at run-time, to allow the application to perform object creation if a class doesn't exist.

Return to [ EDMA's home page | GNU's home page ].

Please send FSF & GNU inquiries & questions to gnu@gnu.org. There are also other ways to contact the FSF.

Please send comments on these web pages to webmasters@www.gnu.org, send other questions to gnu@gnu.org.

Verbatim copying and distribution is permitted in any medium, provided this notice is preserved.

Updated: $Date: 2006/11/22 06:59:11 $ $Author: ramprasadb $