[prev in list] [next in list] [prev in thread] [next in thread]
List: kfm-devel
Subject: Re: language bindings and CORBA
From: Simon Hausmann <tronical () gmx ! net>
Date: 1999-08-25 21:38:22
[Download RAW message or body]
On Mon, 23 Aug 1999, Jim Rucker wrote:
>
> I've been using CORBA for a while at work and from my experience
> I've learned that CORBA is great for language independance and for
> allowing functions to be called on objects across a network. I know that
> kde has chosen MICO as it's CORBA ORB, but I've seen very little being
> done with it. When I first heard about MICO and KDE, the following is
> what I expected would be done:
>
> 1. All Desktop functions would be defined in IDL
> 2. Work would be done to make CORBA language bindings for all the
> supported languages
> 3. A Naming and Trading service would be created when KDE fired up, and
> would allow federation
> 4. Applications could exposing their interfaces in IDL, which would
> allow scriping and access from other programs
>
> With these 4 items, you would be able to perform the following:
> 1. Write programs that would use to the KDE desktop functions in any of
> the supported languages
> When new languages are created, just writing a language binding
> would be enough to allow that new language
> to use all the desktop functions as well as to interface to
> programs with exposed IDL interfaces
> This could replace using Python in KSpread with use any language
> with KSpread
> 2. Programs would be "Network Location Independant"
> Programs running on one system could be made to display on
> another systems display
> Several people could work on the same spreadsheet at the same
> time from their own terminals
> Computation intensive programs could be split accross multiple
> machines easily
> 3. The current ability to create embedible objects could include objects
> written in any language
> 4. The naming and trading services could be used to find specific
> objects or objects of a specific type, such as
> 'spellchecker'
>
> If I could get your feedback on this, I would appreciate it. I'm
> hoping to understand KDE a little more, and specifically MICO's role in
> KDE so I can make contributions in the future.
I'll try to explain the current status of the CORBA integration in KDE:
- We have a full-fledged component model, called KOM.
- We have a technology, based on KOM, called OpenParts, which deals with
the graphical embedding of components and with managing shared GUI
elements
- kded, the KDE Daemon, provides (beside other things) a service for
activating and accessing CORBA based services, in conjuction with MICO's
mediators.
The amount of applications making use of this technology is growing.
slowly but growing :P
To name some:
- the KOffice project (read: all KOffice components)
- Konqueror
- KDesktop
- KView
- Caitoo
Well, and you can read many serious postings from several application
autors planning to add a CORBA interface to their app.
The reason why we don't use COS Trading or Naming is quite simple: it
provides features we don't need, while eating lots of memory though..
kded provides a trader, which expression parser is based on the COS
Trader, it doesn't trader CORBA Objects though. Instead it deals with KDE
Service and Servicetype objects, from the registry.
And there's also a little naming service (eating far less memory than
mico's nsd while providing nearly the same functionalty..) , but it will
likely be removed and replaced by a mechanism to tell the mediators about
a running server "from outside" .
Torben Weis slimmed MICO down, meaning he removed all stuff not
used/needed in KDE (for example the IR), in order to decrease memory usage
and compilation time. His changes (will/are currently) merged with the
"real" MICO sources, probably coming together with the minimumCORBA specs.
....AFAIK.... :P
Need more (detailed) info? ask here :-)
Greetings,
Simon
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic