Re: Questions

[Frederick I Gleef <gleef capital net>]

On Wed, 24 Jun 1998, David [iso-8859-1] Martínez Oliveira wrote:
> First of all, thank you very much for your answers.

No problem, you are quite welcome.


> >I am interested to hear more about EDMA.  Is it something to go on top of
> >a CORBA or COM implementation, or does it serve the same purpose?  Does it
> >handle network communications, or is it only between programs on the same
> >machine?  
> >
> Well, EDMA is mainly the same as COM, a system for packing classes as
> components and link dynamically their in the applications. In this sense
> the system is related to the same process in the same machine.

So are you saying that it is a separate implementation of a component
object model than CORBA or COM, but it leans more towards COM in features
and design?

 
> What I had added is an extension system that I call SIU. This systems
> allows the programmer to create classes that subtitute the EDMA primitives
> (create and destroy objects, property acces and method invocation). So, you
> can write code to send this primitives to other process or machines (I had
> a simple system for remote object interaction). I had another SIU extension
> (in development) for using Java classes within EDMA as their was EDMA classes.

So EDMA+SIU allows for distribution of EDMA components across systems, but
EDMA does not support it directly?


> I will like to use CORBA as distributed system. I think that what I must to
> do is an special Object Adapter for manage EDMA implementations. I must use
> DII for EDMA-CORBA because all EDMA operations are done at run-time. Is
> this the correct way?

I'm not as knowledgeable about CORBA as I should be, but I think that
sounds right.  Since an EDMA program does not use IDL stubs, incorporating
DII into EDMA should allow for EDMA programs to talk to local EDMA
programs using EDMA, and talk to CORBA programs and remote EDMA programs
using CORBA.

One issue I can see already, is I don't know how ORB-specific a DII
implementation has to be.  For example, if you write a DII implementation
using MICO as the ORB, how hard would it be to run on a system using ORBit
as its ORB?  Would it require recompilation, or a full rewrite?

 
> I tried OmniORB but DII is not implemented. I tried Mico too, but I can
> compile it in my Linux box. 

What problems were you having running Mico?  Post your Mico compilation
questions to gnome-list@gnome.org.  Give detailed error messages, it makes
it easier for others to figure out what might be wrong.

Chapter 6 of the Mico documentation discusses implementing a DII interface
between Java and Mico.  A lot of this would be relevant for EDMA.


> >Whether or not this is a good place for this discussion partially depends
> >on what it is you are looking for.  On one hand, I suspect that EDMA as a
> >whole would not fit well with GNOME.  On the other hand, it is clear that
> >you have put in a lot of work and research into component programming, and
> >ideas and possibly source code you developed working on EDMA might be of
> >great use here.
> >
> I had been talking with rms@gnu.org and he tell me that will be interesting
> that EDMA work well with GNOME. I couldn't install GNOME upto the moment
> because I can't install Mico on my system (I still know what's the
> problem), so I don't know very much about GNOME, and then I don't know the
> way that EDMA will work with it.
> I think that the way is making EDMA work with CORBA. Any suggestion will be
> fine.

Yes, since GNOME is being designed to work with CORBA, making EDMA work
well with CORBA will help it work well with GNOME.  If EDMA works well
with CORBA and GNOME, and EDMA offers some functionality or other
advantage over the more 'traditional' IDL stubbed CORBA, you might find
some GNOME applications starting to use EDMA.  But first, you need it to
talk to CORBA.


> [...snip...]
> >LGPL definately looks like the way to go for EDMA, particularly if you
> >want anyone on the Windows 95 end to touch it.
> >
> What does this means?. Sorry I understand this phrase.

Sorry, all I was trying to say was that since the bulk of EDMA appears to
be libraries, LGPL is a good thing, since it allows for a developer using
it to have more license flexibility.  In addition, since most Windows 95
developers unfortunately do not want to use the GPL, this license
flexibility is critical if you want the Windows 95 implementation of EDMA
to have any development.


Best of Luck,
-Gleef