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

List:       kde-devel
Subject:    Re: Common server activation
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-06-26 8:53:52
[Download RAW message or body]

On Fri, 25 Jun 1999, Havoc Pennington wrote:

> 
> Hi,
> 
> OK, let's separate this thread from the specific dialup connection issue.
> CORBA may well be too bloated for that, but we will need it elsewhere 
> regardless.

Yes, I agree that it would be really nice to have at least some common
CORBA related standards between KDE and GNOME. Although we have different
object models it is still CORBA, and IMHO it's something that "connects"
both environments.

> BTW, I cut kde-devel from my CC because my mail will bounce, others may
> want to re-add it.

Ask Martin Konold <konold@kde.org> for write-access.

> On Fri, 25 Jun 1999, Simon Hausmann wrote:
> > 
> > Yes, and comparable to libgnorba we have the KDE daemon and libkded, also
> > KDE specific.
> > 
> > Since the activation of servers is ORB/Desktop specific (we use the IMR
> > and mediators from MICO in KDE, and GNOME has the GOAD, right?) we might
> > want to find another way. And in case of this internet-dialup service
> > thing (as a daemon-like service, or?) I guess a simple approach to get the
> > IOR easily from both Desktop Environments should be sufficient IMHO.
> > 
> 
> Do you think a simple IOR approach will work for more complex cases? I
> think we need a general solution.
> 
> I'm not an expert in this area; I am just having to do the talking until
> we get a CORBA-head to help. In particular we are going to have to
> convince Elliot to give us advice. :-)

Well, I don't see a better way now. But I might be wrong.

I agree that it would be nice to have a common standard for the actual
activation of a CORBA services, but I fear it's (at least currently)
impossible.

The problem I see is that the two approaches are very different:

IIRC, GNOME (libgnorba) uses it's own mechanism of starting a server,
getting an IOR (via pipes, right?) and re-using (depending on startup
flags) an already running server (you perform a lookup in the naming
service to check this, right?) .

KDE, in contrary to this, uses already existing code, provided by MICO,
in particular the IMR and mediators for BOA/POA (plus the BOA as is, which
has the builtin functionality to load shared libraries (depending on the
activation mode) . 
The "result" , meaning that servers get re-used if they're already running
(depending on the activation mode) , and meaning that they get started
automatically (via libgnorba <-> mediators from MICO) is equivalent in
both desktop environments, however both approaches are incompatible.

So far, the two approaches are simply said incompatible. You cannot
startup a libgnorba based server with the kde daemon/MICO and vice versa. 
While the GNOME approach seems to be independend (so far) from ORBit, the
KDE approach in fact depends on MICO.

But IIRC GNOME CORBA Servers depend somewhere else on ORBit, when it comes
to security:
The kde daemon uses a unix socket for IIOP, for security reasons .
libgnorba (AFAIK) goes a difference approach by using cookies for this,
but AFAIK the mechanism depends on ORBit. I saw calls like
"ORBit_set_request_validation_handler" in the cookie security code, and
that's why I thought that they're ORBit dependend. But I might be wrong, I
couldn't find similar functionality in MICO though, so that's why I guess
it's an extension of ORBit, not available in MICO.
This would make any kind of CORBA server incompatible between GNOME and
KDE, for authorization.
But perhaps I didn't read the GNOME code carefully enought, so I might be
wrong.

> > Two ideas come to my mind in order to get this IOR:
> > 
> > 1) Use a naming service. IIRC Gnome uses the COS Naming Service from
> >    ORBit. KDED has it's own, smaller (and more simple = less features but 
> >    less memory consumption) Naming Service, incompatible with COSNaming.
> >    The approach to actually get the IOR of this naming service (or kded
> >    in case of KDE) is the same in both environments -> a special property
> >    on the X root window.
> > 
> >    So I think: If we can arrange on a common property for the naming
> >    service in both environments _AND_ a common IDL for the naming service,
> >    then we're done :-)
> > 
> 
> I think it would be awfully nice to have a solution that doesn't depend on
> X. My understanding is that we use X for authentication, though.

Yes, that's why I understood from the libgnorba sources, too. But IMHO
there's nothing wrong with your approach in general. While developing the
kde daemon we thought about a similar approach, but we couldn't find a
proper solution for cookies (Steffen - can you comment on this, please :).

> The reason is that many of these services - such as the dialup connection
> thing - are not GUI-dependent, and we want to get non-GUI apps to use
> them. We are creating a free-Unix-standard, not really just a desktop
> standard. At least, that's what I think we should do.

I agree with you that it would be nice to have a gui/X11 independend free
standard, the way to achieve the goal seems to be hard though :-)
 
> > So assuming that the last paragraph is no problem and assuming that 2) is
> > not preferred by anyone, IMHO the naming service would be a nice
> > thing/approach. But we need a common IDL (or use the COSNaming interface 
> > for both environments) or it first.
> >
> 
> Can someone from KDE give their objections to COSNaming, if any? Is it
> feasible to adopt it in both environments? (While keeping whatever you
> have now for backward compat, of course.)

Well, I implemented the KDE naming service. In fact it's a very simple
thing, just like COSNaming, but with the major difference that it doesn't
support sub-contexts. It's just a simple map, mapping names to objects and
vice-versa.
The reason why I did this is that I thought (and still think in somehow) 
that we don't really need the full-fledged COS Naming Service. It surely
provides nice features, but I doubt that they will be really necessary,
given the fact that it's still bigger (in memory/code) than a simple
self-made naming service.
And IMHO it's worth to save resources since the feature of sub-contexts
can IMHO be solved simply by using "hierachical names" for objects. So
instead of creating a special naming context "GNOME", with another extra
context named "Editors", just in order to "store" the object named
"fooeditor" in it, something like "GNOME/Editors/foo" as name does a
perfectly equivalent job IMHO, with less memory/code consumption for
extra naming contexts. If we use such a naming convention in a 100%
consistency way, we should be fine IMHO.


Ciao,
  Simon


--
Simon Hausmann       <hausmann@kde.org>
http://www.kde.org/  <tronical@gmx.net>

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