Hi At least I've found some time to update GEP3 with Elliot's comments. The new version is now in CVS and attached to this mail. Please, Elliot, tell me if I've forgotten some important things from your mail, since I've just added a quick summary and may have forgotten some important things. Also, I found out the discussion end date for this GEP is tomorrow (Oct 1st). So, I wanted to ask for a delay of the end date, since I've found there are a lot of new things I didn't add at first to the GEP, which I've been finding out thanks to Elliot and other people comments. That is, adding remote support to bonobo-activation seems to be a complicated task, so it may need a lot more thinking than we've done so far. Maybe it's not that difficult and only it's my ignorance on b-a's internals, but at least the delay would allow me to understand the issue, since I started this GEP :-) so, is it ok to delay? any comments on the new additions I just made? cheersTitle: REQUIREMENTS GEP 3: Support for remote activation in bonobo-activation
This GNOME Enhancement Proposal documents the changes proposed for adding support for activating remote objects in bonobo-activation.
One of the missing gaps in the GNOME CORBA support is the possibility of activating remote objects (that is, components that are installed in remote machines). To add this support, a few changes on the bonobo-activation architecture are proposed in this GEP
The idea is to be able to install network-wide components, that can transparently be activated from other machines, as well as having those components appear in the queries made from client machines. This will allow things like company-wide services to be installed in dedicated machines, and having network clients activating those services via CORBA over the network.
For this to work, support must be added to bonobo-activation to be able to bootstrap to other bonobo-activation servers running as a specific user on other hosts. This is needed to have the remote servers stored as ObjectDirectory objects in the local bonobo-activation server. Once this is done, objects published by the remote servers will appear in all queries made to the local bonobo-activation server.
It must be possible to have the remote activation system support session management, as well as other things such as desktop theme (for UI components, like controls or embeddables), configuration database, etc, so that remotely activated components act just as if they were local (ie, transparently to users or applications).
It should also be possible that the object directories the server bootstraps to is configurable at an enterprise, system and user level. GConf is intended to allow configuration to be manipulated at all these levels.
The bootstrapping or 'root DNS' problem needs overcoming in some fairly elegant fashion, for the service to be useable.
For this, the bootstrapping could be added to the ActivationContext, which is the one which has the list of activated ObjectDirectory's. Also, ActivationContext's should continue to be on a per-user per-machine basis, thus just serving as a convenient place to list all the ObjectDirectories in the known universe.
The bootstrapping operation could be overcome by connecting to the remote bonobo-activation system via a remote daemon on a known port (via inetd/xinetd); or by remote ssh based activation
On the client side, once the ObjectDirectory's of the different bonobo-activation servers have been bootstrapped, the activation of local or remote components should be totally transparent to users, which will query bonobo-activation as usual, and will get the AIDs for the different components available.
Also, the query language will need a few more attributes added to allow apps to specify things such as which display an active object should be on, whether an object is on the local machine, which "group" an OD is in, etc.
There is a need also to determine where a newly created servant is to be registered (that is, which ObjectDirectory will be used by bonobo_activation_active_server_register). For this to work, there must be a notification method so that ActivationContext's and ObjectDirectory's can notify each other about events (new servant registered, servant gone, etc).
A general facility for associating properties with activation records (such as which $DISPLAY to run in) could be added, so that queries can check those properties to see if an existing activation satisfies the request.
For the network communication between the different bonobo-activation servers, security must be addressed. Specifically, we need:
None yet.
None yet.