EDMA Tech-Info

[David Martínez Oliveira <dmartin tsc uvigo es>]

Since Friday I see some interest about EDMA so I post this message with a
more technical information about EDMA, in order to people to get a more
clear idea about what EDMA is, and then evaluate if it will be usefull or
not. I will write some english docs when I had some time.

EDMA is a shared library that an application can link at run-time, and that
offers an object-oriented environment for interacting with objects. EDMA is
about 80 Kbytes long. When it is inited, it creates some tables for
maintain system information.

Common information is stored in shared memory. This common information is
some system-wide global variables, the object table and the class table. I
don't have information about the size of this tables at this moment, but
they can be configured (at compile-time, at the moment). In the class table
EDMA stores class's interface information. The current version fill this
information at start up, but I will modify this for adding interface
information dynamically when it will be necessary (when an object is created).

ANother class and object tables are created for maintaining process depend
information such as method pointers, dynamical inheritance information,
etc... THis tables are much more little that the other, any entry at the
table is a few bytes long.

When an applicarions links EDMA (this process is made dinamically), the
library checks for global variable. If they don't exists does the full
initation secuence, else, it only initiates process dependent tables. In
initation process EDMA hadle a class registry, a file that list all the
registred classes at the system. With this information, EDMA fills tha
class table with information as the library wich implements its methods,
the SIU system where it may run, or de parser used for processing interface
files, etc...

Any time an application creates and object (calling NewObj("CLASSNAME"))
EDMA look for class information at these tables, load the implementation
code and creates local storage for the object, for properties and virtual
method tables. This primitive returns and object identifier for interacting
with it.

EDMA uses string identifiers for accessing object's properties and methods.
This strings works as trees in file systems in order to access the class
diagram associated to the object. The access to the properties and methods
of the object's class is direct. For accesing superclass you must indicate
the class path. For example, an object of class BUTTON which derives from
WINDOW, can access the method "Size" of the class WINDOW using the primitive: 

Met3 (idObj,"WINDOW/Size",400,400); 

where idobj is the object identifier returned by NewObj.

EDMA implements on-demand inheritance, that is if you specify and class
path that doesn't exist, EDMA builds it. If you have a CONTROL class for
managing GUI controls events, you can add it to the object BUTTON simply
executing:

Met3(idObj,"CONTROL/OnMouseDown",MyMouseDOwnHandle);

This command, first adds class CONTROL to the object idObj and then
executes the method. Since, EDMA allows dynamical virtual method override,
this things can be done and then application development can be easiest and
code reuse more powerfull.

Last, SIU extensions allows to add new funcionalities to objects without
changinf EDMA code. As example, I will show how to use the FAYE system, a
SIU system for object distribution. FAYE defines a SIU proxy that
represents the remote object in the local system, this proxy receives the
user primitives, then packs them and send it to the remote system. The
fact, is that for doing this you simply must to specify wich SIU proxy
wants to use when object is created. In the FAYE system this looks like this:

idObj=NewObj("FAYEPROXY:(myhost.mydom.es:2069)IMAGE");

THis will create an IMAGE object at machine myhost.mydom.es at port 2069. A
server must be launched at this system. The CORBA integration will be done
in this way, creating a SIU PROXY and than gets EDMA primitives information
and transform them in a DII call to ORB. THis will look like this:

idObj=NewObj("ORB_ORBit:OBJECT_IDENTIFIER");

The SIU proxy ORB_ORBit will transform this request in the CORBA specific
command.

The SIU proxy are EDMA classes that reimplements the main EDMA primitives
(NewObj, FreeObj, WProp3, RProp3, Met3 and Met3S). THe implementation of
this proxy get all the information that EDMA have about the invocation and
then the proxy must use it for make the equivalent request for the target
system (CORBA for example). THis is the reason for using DII for
interfacing EDMA and CORBA. All EDMA primitives uses strings so they can
not be statically linked.

This is a very general description about EDMA. I hope that this will
provide a more clear view of the system in order to make comments,
suggestions or evaluate the advantages on using EDMA in the GNOME project.
Any question, suggestion, comment, ... about EDMA will be wellcome.

In the actual distribution can be found a lot of simple examples on using
EDMA. You can download it from http://wgpi.tsc.uvigo.es/~dyc/EDMASite on
the download section at left frame.

I am a bit busy this week, but I hope to add the source code at the web
soon, with an english version of the pages (well, I don't know if will be
worst the english pages than the spanish ones, as you can see).

Thanks very much for reading this note and sorry for my poor english.

------
-------------------------------------------------------------------
David Martínez Oliveira

E-mail: dmartin@tsc.uvigo.es
Personal WEB Page : http://wgpi.tsc.uvigo.es/~dyc
EDMA WEBSite      : http://wgpi.tsc.uvigo.es/~dyc/EDMASite
--------------------------------------------------------------------