Re: GNOME Baboon

[Miguel de Icaza <miguel nuclecu unam mx>]

> >     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.  
> 
> This is handled by the implementation repository (with support from the
> server itself)

Yes, it is, but the "activation" facility should be aware of these.

> >     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.
> 
> As I suggested before, I think we can tell objects the display to use in
> Context attributes.

Gtk applications can only send output to a single X server.  There is
no way to make a Gtk application be able to display on two different
servers.  This means that for each display the user has, a new
server has to be started.

> >    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):
> 
> I don't think the baboon_get_factory routine should either know about or
> care about how the server is implemented. Object activation should be 
> totally transparent to all client requests.

It has to know this information, given that it has to choose to launch
a new server if no running instance of the server has the properties
we need (specifically: the boundness to an X server).

> If an object has registered with the name service, there will be a 
> name->objref mapping. If an object has been registered with the implementation
> repository, that object can be started and stopped transparently to any
> clients.

I want to avoid starting multiple servers if a server that suits me is
already running, this is why I want to check the naming service first
for an object that matches my criteria and if no object is found, I
then ask the implementation repository to launch the object.

> We may have to preload the factory objects so that the name service knows
> about them.

So, the name service can launch objects that are not active?  I
thought the naming service just had a mapping between running objects
and their names, not a general purpose launching facility.

> "We" dont have to do anything - the object will be activated for us when we
> try and use it.

Can you explain us how this fits in ORBit so that I can go and code
this?  At what point do we "try" to use the object?

What would be the steps involved in doing this?

Say I want to get a handle to a Gnumeric server running on the current
display, what steps would be involved?

> IMHO, the only daemon that needs to be run is the implementation repository
> itself. We can find the name service object via resolve_initial_references(),.
> and from there we can locate any other object that has bound names in the
> name service.
> 
> When a service is requested, the implementation repository will take care of
> _all_ of the details of starting servers, whether they are in-process, 
> machine-local, or remote and whether they are factories, single-object
> processes, or multi-object processes.

Excellent.  So we just need to provide auto configuration/auto
launching of the implementation repository.

Cheers,
Miguel.