Re: Common server activation



On Mon, 28 Jun 1999, Miguel de Icaza wrote:

> 
> > Now tell me why we should not store this info in the applications
> > .desktop file? 
> 
> Consider Gnumeric.  Gnumeric supports various interfaces:
> 
> 	 GNOME::GenericFactory (for creating new toplevels)
> 	 GNOME::Gnumeric::Workbook (workbooks)
> 	 GNOME::Gnumeric::Sheet (sheets)
> 	 GNOME::Table
> 
> And will support regions and GNOME::DBTable soon.
> 
> This means that a single program is providing a pile of different
> interfaces.  
> 
> You need a special setup to store all of this information there, plus
> any extra information you might need about the server.  Our new setup
> conteplates contraints as well (so you can specify which interfaces
> are supported for each toplevel interface trough QI).
> 
> We need to support multiple servers and factories in a single
> executable.
> 
> > I can somehow understand your point if it comes to plain CORBA
> > servers, but on the other hand .gnorba files look like striped down
> > .desktop files to me.
> 
> Then I guess to you win.ini looks like a big .desktop file, right?
> 
> Seriously.
> 
> They contain *ortogonal* information.  The .gnorba file contains
> information about activating servers and the way those servers are
> exported.  If you look at .gnorba you will see that the information
> there has nothing to do with the information in a .desktop file.
> 
> That being said, the new file format for the new .gnorba files is
> going to be an xml tree.

I see that this is a similar approach like we have, we are not using XML
though but we stay with the .desktop format.

When an exectuable "contains" multiple servers, then we put the
corresponding repoids (for activation) in a list entry.
Besides that we can query the supported interfaces at run-time, that's
part of KOM, we can (and actually do that) simply specify a list property
for the specific servicetype, describing the supported interfaces.

But well, I guess it doesn't make sense to discuss about our two
different approaches. We are going different ways here, and that's it.
But I think this doesn't prevent us from still sharing this common
information (your XML files, our .desktop files) , since we actually need
it if we really want a common standard for the activation of CORBA
servers (I'm looking forward to Elliot's drafts)

Since the actual information is the same (different storage though) , we
could define a common interface for this. Your implementation will read
your .gnorba-xml files and our's will access the .desktop files.

I think it is the only possible solution anyway since the registry systems
of both projects seem to be completely different anyway (except for the
panel-menu/desktop entries of course) .

For querying such data we use a simple trader, where you can specify
constraint and preference expressions, 100% like with the COS Trader (the
reason for this is that the code of it is derived from the mico traderd,
written by Torben :) .

How does your approach look like here?

> Now, what about display-less servers, that have *no business
> whatsoever* with the display, those also get a .desktop file in your
> setup?  

Yes, we have directory for that, for all kind of service implementations
which are not already part of an application, which .desktop file is in
the menu-tree (applnk) . This is not fixed to CORBA servers but it's
available for all kind of services.


Ciao,
  Simon

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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]