Re: GNOME Baboon

[Walt Pohl <pohl math washington edu>]

I'm not an expert on this, but I think that the POA is supposed to handle
the vagaries of activation.  When your server starts up, it creates a POA
with whatever activation policy you want (one server per object, one
server for many objects, etc.), and then its the job of the ORB and the
POA to take care of everything else.  (Everything I know about the POA I
learned from Doug Schmidt's papers, so my knowledge is currently strictly
theoretical.)

For factory objects, there is a Life Cycle Service, which suggests some
interfaces to deal with factories.  Instead of using the Naming service,
it offers a FindFactories method that works with the name directly.

What I would think would be better would be a method that takes an object
from the Interface Repository (an InterfaceDef), and then provide a GNOME
service that looks up factories based on that.

Doug Schmidt in his papers has the interesting suggestion that when you
write a server as a separate process, write the server so that it can
serve as a factory as well.

On Wed, 12 Aug 1998, Miguel de Icaza wrote:

> 
> 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. 
> 
> 
> 
> 
> -- 
>          To unsubscribe: mail gnome-components-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.
>