GNOME Baboon

[Miguel de Icaza <miguel nuclecu unam mx>]

Hello,   (Dick specially)
   
    Here are some of the issues we are trying to address for CORBA in
the Gnome framework.  You can find this document in the module
baboon/docs/activation.txt  in the CVS server as well.

Best wishes,
Miguel.

-----------------------------------------------------------------------
We need to address a number of issues for the component model in
GNOME which we are calling "Baboon".

* Use of CORBA in the GNOME desktop

The component model will be used in a number of different scenarios,
and we need to provide the functionality for Baboon to be used in all
of the following scenarios:

        1. Components:  There are pre-packaged libraries/servers that
           do provide some functionality that can be used by any
           application like spelling servers, calendaring services, a
	   computation server, and other non-GUI services:  Think of
	   these as dynamic libraries.

        2. Application/document embedding and in-place activation:
	   The Baboon interfaces for document/application embedding and
	   interactions are being modelled after the OLE2 and OpenDoc
	   interfaces. 

        3. GNOME Applications as service providers:  GNOME
           applications will export their inner workings trough CORBA
           to allow anyone to reuse their functionality.

           This allows scripting of the GNOME desktop as any
           CORBA-aware application or scripting language can invoke
           methods in a GNOME server (for example, a script in Perl
           can control remotelly a spreadsheet to make a graph or to
           make a sales report).

           Some people call this "Automation".  Unlike the COM world,
           the use of CORBA makes this transparent to the
           implementor of a server.

        4. Reusable controls: Another set of Baboon interfaces deal with
           reusable conrtols.  This is similar to Sun's JavaBeans and
           Microsoft Active-X.

* Issues to be addressed for Baboon.

1. Activation

    We need to provide a simple way for application to start up
servers on demand.  Something that will allow an application to get
access to a CORBA server that would provide the services required.  

    A server can be implement in various ways: some servers might
require one process per instance;  some other servers might be able to
process multiple requests with a single server.  

    And to complicate things even further: there are some servers that
are going to be bound to a specific X display.  Basically, every
server that uses Gtk will be bound to an X server.

1.1 How to create a new instance of an object.

    From a conversation with Elliot, I think we need to implement
Factory objects.   These factory objects would provide a method that
returns a new object when requested.  

    For example, to invoke the spreadsheet, the code would make a call
like this:

	Factory *sheet_factory;
	Spreadsheet *sheet;

	sheet_factory = baboon_get_factory ("Spreadsheet");
	if (!sheet_factory)
		return "cant activate spreadsheet";

	sheet = (Spreadsheet *) sheet_factory->create_instance ();

    The Baboon libraries would internally call the Name service to
check if a SpreadsheetFactory object is running and if so, get a
handle to it.  If the SpreadsheetFactory is not running, then it would
be launched and the baboon libraries will wait for the server to be
registered with the naming service. 

1.1.1.  baboon_get_factory magic.

   First of all, the baboon_get_factory routine should check how the
factory being requested should be activated (I guess this information
is kept on the Implementation Respository):

	1. Shared library (in-process server).
	2. One-server per factory.
	3. Server can create multiple instances.

   Case 1: library is loaded, factory invoked.
   Case 2: server is launched and we ask him to contact us when it is
	   ready. 

   Case 3 is the only interesting one: this one has to find out if a
server is running and it satisfies our requirements.  I suggest we do
this by using the CosNaming service.  For the sake of discussion, lets
assume we have a routine that takes a pathname separated by slashes
that returns a handle to an Object if the object is found on the
naming server:

	CORBA_Object baboon_locate_server (char *server_path)

   baboon_get_factory would attempt to get a for the class factory in
the following order:
	
	"/GNOME/servers/display-less/$factory_name"
	"/GNOME/servers/display=$DISPLAY/$factory_name"
	
    (I am using shell-expansion-like in the above examples)

    if one of those servers are registered, then the object handle is
returned to the caller application, if it is not, then we would have
to launch the server (from the implementation repository) and wait for
the server to register with the naming service.

    The implementation repository might of course activate objects on
a remote system if it so desires.

1.2 Naming service, implementation repository

   Because of security issues, we want all of the servers to be ran
under the same UID of the user and we want the user to be able to
extend the implementation repository with its own provided servers
(which can be local or remote, and without having access to the system
installed servers and configuration files).

   Thus, the implementation repository and the naming service for the
user will be a daemon launched the first time the user process invokes
a baboon/ORBit service.

   So, we need ORBit/Babbon applications to automatically configure
themselves to locate a running name-server/impl-repository when they
startup; this means: none of the MICO approach of passing IORs or
internet addresses on the command line to find its servers. 

   A simple approach for this would be to create a protected directory
in /tmp/ORBit-$user/ and stick a socket there where the naming
server/implementation repository daemon

1.3 Security

   I do not know what is the plan with ORBit about authentication: I
know the hooks are there, but I do not know if they will get used by
default to provide authentication over inet sockets.  In any case, any
service launched by Baboon and any server providing Baboon services
should be using that.  

   So, if ORBit does nto handle authentication by default (because it
might make sense to not dictate the policy) then we should provide
wrappers that set up the authentication by default.