[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    kidl (was: Re:The MICO/CORBA Issue.)
From:       Simon Hausmann <shaus () uermel ! Med ! Uni-Magdeburg ! DE>
Date:       1999-09-18 14:07:18
[Download RAW message or body]

On Sat, 18 Sep 1999, Lars Knoll wrote:

> > I volunteer especially for the script-writing needs (to convert apps). :)
> 
> I'd volunteer to help a bit too

Great! :-)

I have the following technical issues in my mind, regarding the IDL->QT(L)
mapping:

1) integration into MICO?

   I think we have two possibilities:

   a) We either add our code to MICO's codebase

   or

   b) We attempt to be smart and keep our code separate.

   Both approaches have their advantages. 

   For a) we have easy access to the IDL parser, especially in regard to
   the problem of finding out about #include'ed files. libidl's
   database provides access to a repoid->filename mapping.
   The disadvantage is that we have to deal with the MICO guys about
   how to integrate our code and we also depend on their release schedules.

   How to keep our code separate?
   The answer is simple, and Torben implemented this twice: In pymico and
   ksidl he does this:
   - launch mico's interface repository deamon
   - launch mico's idl compiler and tell it to feed the output into the IR
   - parse the IR (centralised in the ird) and generate the output code
     (mapping code)

   The disadvantages/problems are:
   - we do not have direct access to the idl db, so we will have to
     attempt to find out about #included files in another way (only
     through the IR) . ksidl *can* do this AFAIK, so we might find some
     hints in there.
   - The performance for generating the code will be poor, compared to the
     mico's idl compiler.
   - clients will have to link against yet another lib (see below)

2) more details.. :)

Yet I've been playing with the second approach (mentioned above) .

I think our code will exist of two major elements then:

A library containing our (de)marshalling code, code which translates
between the Qt container types and MICO's SII types (StaticAny, etc.) . We
might create a special header file which our generated code should
include, instead of CORBA.h . Beside our translation code we
will probably have to include *some* basic mico header files (for
CORBA::Object, CORBA::Any, etc.) .

The second element is our IR parser then.


I probably missed some points and I also might have misunderstood the SII
thingy - I hope Torben can comment on this. Anyway, this are my first
thoughts and experiences from the code I wrote in the last hours :-)

What do others think? Which way shall we go?

Ciao,
 Simon

[prev in list] [next in list] [prev in thread] [next in thread]