Re: Object activation for GNOME.

["Geoff Brimhall" <gbrimhall Rational Com>]

Though this might be opening up a sore, what was decided on the issue of being able to work directly with a v-table for an object, which is something that COM gives you if you instantiate an object in-process ?

The last I had seen it was decided against this since COBRA doesn't allow such direct access.

Thanks for any enlightenment.

Geoff Brimhall

-----Original Message-----
From: miguel@nuclecu.unam.mx <miguel@nuclecu.unam.mx>
To: gnome-components-list@gnome.org <gnome-components-list@gnome.org>
Date: Wednesday, July 29, 1998 11:02 AM
Subject: Object activation for GNOME.



Hello guys,

   Since ORBit has been an absolute success, I got all excited about
the gnome components.  I have been working recently on the spreadsheet
for the GNOME project, with the idea of making it the testbed for our
components and our document model.  

   I also have been catching up with Microsoft's way of doing things
and their Common Object Model.  I do believe they have some very
useful ideas that we should definetly get our hands on and make them
part of our component model.

   Here is a list of things I want to implement for the gnome
components based on 

* Component Activation.

   Microsoft's COM provides three API entry points for dealing with
   objects:

1. Get a pointer to a class factory (ie, a class whose only
           purpose is to create instances of an object).

2. Create an instance of a given object type (this is
           basically (1) with an implicit call to create an instance).

3. Load an object from a file, invoking any constructors
           required for this (obviously, layered on top of (1) and (2)
           and an extra routine or two).

   The interesting part is how do you get your hands on a class object
in the first place?  Microsoft solves this with the Registry[1].  This
just happens to be a database with useful values (For the sake of this
discussion I am going to use a gnome-config like database format here):

   Lets imagine we want to get create a PlotObject.  Here is my
suggested API for component_get_class_object:

You would write this fragment of code:

     CORBA_Object plot_class;
     PlotObject plot;

     plot_class = component_get_class_object ("PlotObject");
     plot = plot_class_create_instance (plot_class, &ev);

     plot_set_values (plot, ...., ev);

The database of our servers would include this:

[PlotObject]
Type=SharedLibrary
Filename=/opt/gnome/lib/servers/plotobject.so

[CalendarServer]
Type=Standalone process
Filename=/opt/gnome/bin/gnomecal --someoption

    At this point, our component wrapper routines will load the object
from the shared library and would call a function in the shared
library called get_class_object with the object name as a parameter),
this could be implemented like this (note, this example shows a shared
library that implements two different objects):

char *
get_class_object (char *str)
{
static int server_registered;

if (!server_registered){
component_register_server ("PlotObject");
component_register_server ("SomeOtherObject");
server_registered = 1;
}
if (strcmp (str, "PlotObject") == 0){
   return (init_and_create_plot_object_class ());
} 

/* This is only needed if a shared file implements
* more than an object in the same shared library 
*/
if (strmp (str, "SomeOtherObject") == 0)
   return (init_and_create_some_object_class ());
}
   

In the case we wanted to create an object of a class that is
implemented as an external process, the component library would launch
the process and wait for the process to register their servers with
some sort of daemon that keeps track of the existing servers running
on behalf of the user, like this:

main ()
{
component_init ();
printf ("Calendar server starting up\n");
component_register_server ("CalendarObject");
component_register_server ("TodoObject");
component_register_server ("AlarmObject");
component_main_loop ();
}

Now, this is how I would implement it today.  And I am mailing this
list to get input from all of the people that known the CORBA
specification up and down to guide me in the right direction.

Miguel.

[1] actually, the Registry happens to be a cache of the actual values
that might reside on a remote server.  




-- 
         To unsubscribe: mail gnome-components-list-request@gnome.org with 
                       "unsubscribe" as the Subject.