Re: Common server activation

[Simon Hausmann <tronical gmx net>]

On Sat, 26 Jun 1999, Havoc Pennington wrote:

> 
> On Sat, 26 Jun 1999, Simon Hausmann wrote:
> > 
> > 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:
> >
> 
> Can you suggest a third approach - perhaps one that takes the best from
> each? For now, each desktop will continue to use its own approach; in the
> future, we can gradually transition. I think you're right that each
> approach uses ORB-specific stuff. However, we can perhaps convince Elliot
> to add stuff to ORBit if that's needed, to match a MICO feature or
> whatever.
> 
> I know everyone is attached to the approach they designed, but we *really*
> need a solution here. It isn't just for interoperability; it's also so we
> can migrate CORBA out of the desktops and down into the more core features
> of the operating system.

I fully agree with your points.
 
> > But perhaps I didn't read the GNOME code carefully enought, so I might be
> > wrong.
> >
> 
> I all sounded good to me, but it also sounds like you've read more of the
> libgnorba code than I have. Which is a very good thing. I'm glad someone
> is reading code from both projects.
>  
> > 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. 
> 
> That sounds reasonable. However, I think getting an interoperable solution
> is more important than saving resources *or* the extra features of the COS
> Naming Service. Saving a bit of RAM and avoiding namespace clutter are
> both small, programmer-visible-only problems. With a common,
> GUI-independent standard we add significant user-visible functionality
> (and significant functionality for developers that aren't working directly
> on Gnome and KDE, say the CUPS people who might want to give us a nice
> interface for chatting with the printer).
> 
> So, I would encourage us to avoid getting bogged down in the precise
> technical details; while they are important, the most important thing is
> to have something that works and that everyone can at least grudgingly
> accept. i.e. if a technical argument isn't getting resolved, at some point
> we need to just flip a coin, or say "whoever implements it decides."
> 
> OK, clearly I am not the person who needs to be talking. I am shamelessly
> spamming the Gnome CORBA people, and I hope they will speak up. :-) Is it
> feasible to have a common object activation standard? What problems exist?
> How can we adress them? 

Again: I can just fully agree with your points :-)

Let's see how we can address the problems:

First I think we have to get rid of ORB specific stuff when it comes to
the activation of a server.

For GNOME this means (if I got things correctly) : No more ORBit specific
cookie security handling. I agree here with Steffens points and I think
using normal unix sockets for IIOP should be sufficient for now.
What do the GNOME people think?

For KDE it's a little bit more: We are using the IMR and the mediators,
and we have to say goodbye to both. But I think we can keep source
compatibility, since we are currently hiding all IMR/mediator specific
stuff behind a clean interface.

The next step is the way of keeping track of running servers. I like the
GNOME approach of using a naming service for this. However we have to
agree on common naming conventions, the naming service interface as is,
and other stuff.

In addition we might want to define a standard of command line arguments
for starting a server. For example I'd like to have an option like
"-fooblah ior_of_the_naming_service" , so that a CORBA server does not
depend on a running X (clients however use the IOR published on the X root
window) .

Something else I could think of is a separate interface for registration,
so that a server does not "talk" to the naming service directly but rather
to a "registration interface" , which implementation then does the actual
bind() at the naming service and tries to keep everything clean in there :)
(not that something gets corrupted..)

But so far we've only been talking about running stuff. However there has
to be a way to find out about the installed servers at all. Fortunately
GNOME and KDE use a very similar approach, with some differences though.

AFAIK (please correct me if I'm wrong) GNOME uses the .gnorba files and
stores them in a standard directory. 
KDE goes a similar way and integrates the necessary information in the
.desktop (.kdelnk) files of applications (which are often user-app and
CORBA server in one) and additionally provides an extra directory for
plain CORBA services. (this directory is not only for CORBA services
though, but that's a speciality of our registry system, which should not
affect this discussion) .

The kind of information I'm talking about are three entries:
1) list of repoids
2) path/name of executable (with optional cmdline args)
3) service name

But I'm not very well informed about GNOME's .gnorba files and their
structure, however I think we _could_ put these three types of entries
into the common .desktop file standard as they're used commonly between
both environments. We just might want to agree on standard names of them.
(a fourth key value we use is the activation mode (from the IMR))

That's it so far from me and my understanding/ideas. It's all just covered
by my humble opinion. I'd just like to make a start, so that we can actually
discuss about details/design, and I'd really like to hear opinions/ideas/
suggestions/proposals from other GNOME people as well.

Ciao,
  Simon

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