About object activation.

[Miguel de Icaza <miguel gnu org>]

Hello guys,

   We want to come up with a better object activation mechanism for
GNOME.  The problems in the current setup are:

	1. Object activation depends on an X server to be running
           (because we try to locate our name server by using a well
           known location in the X server).

	2. Currently we support the notion of a GOAD-ID (a specific
           implementation identifier), but we lack category
           identifiers: a way to group similar services by the list of
           the interfaces they support.

	   Although this can be hacked by using "virtual" CORBA
	   interfaces, ie for example, querying for GOAD-ids that
	   implement interfaces A and B, there is no way to activate
	   components that implement interfaces A and B in a simple
	   way.

	3. Lack of a preference system for choosing a specific
           implemenation of a service. 

	   For example, we want the user to be able to choose his
	   favorite editor for editing text files.  We need a call
	   that would map from a "service-id" to a specific "goad-id"
	   and come up with a scheme to deploy these.

    The current code is pretty good if you ignore the above problems.
We want to extend it and upgrade it to work in a larger range of
setups.  Here is a list of wish items:

	 1. Be able to specify the execution domain.  We believe we
            need a system domain (global for the entire system), a
            per-user domain (valid across all sessions of the user), a
            display-user domain (valid only for a single user in a
            given display).

	    I am not sure if we want to keep the current setup which
	    is display bound, but there is no reason to drop it. 

	 2. The current setup loads continously the contents of the
            $sysconfdir/CORBA/servers to load the list of services and
            activate the one requested.

	    We could move the information from a direct file system
	    access to querying a system daemon that would hide the
	    details of where the information is stored.  For example,
	    it could keep the information on memory or as a
	    pre-computed data base on disk to reduce memory usage.

	 3. Object Properties.  Besides the classification of objects
            by categories, we might want to request object to have
            certain attributes "footprint < 2megs".  Although this is
            more of a wish item.

    We would have a name-service running for each domain to access
existing factory objects. 

    Now, there are a number of practical problems that should be
addressed as they affect directly the API exported.

    Firstmost, should we have a single API call that takes a domain
argument to activate objects in the specific domain?  Or should we put
the activation domain information in our .gnorba file?

    ie:

	     enum {
		  GOAD_USER,
		  GOAD_SYSTEM,
		  GOAD_USER_DISPLAY,
		  GOAD_DISPLAY,
	     } GoadDomain;

	     goad_object_activate (GoadDomain domain, 
				   const char *goad_id,
				   int activation_flags);

    or we can have goad_object_activate talk to all available
name-servers and figure out where "goad_id" lives and activate itself?

Miguel.