Re: GEP 3 - Remote activation in bonobo-activation

[Rodrigo Moya <rodrigo gnome-db org>]

On Tue, 2002-09-03 at 08:13, Mark McLoughlin wrote:
> 
> > hi
> >
> > I've just added to the gep module the gep-3.html, which is about adding
> > support for activating remote objects in bonobo-activation. Also
> > attached here.
> 
> 	Some comments:
> 
> 	+ It strikes me that this GEP shouldn't be merely about the actual
> 	  activation of remote components, but the mechanism by which a
> 	  component installed on one machine can be picked up by a query of a
> 	  bonobo-activation on another machine. In fact, assuming we stick by
> 	  bonobo-activation's current architecture this is the first problem
> 	  that must be addressed.
> 
right, updated the GEP to mention this.

> 	  Maybe I better briefly explain how I understand it is supposed to
> 	  work:
> 
> 	  A bonobo-activation server contains a single ActivationContext object
> 	  which holds a list of ObjectDirectory objects. When you query
> 	  bonobo-activation it queries each of the ObjectDirectories in turn.
> 
> 	  An Activation ID (AID) holds the information required to actually
> 	  activate a component - from docs/id-format.txt:
> 
> -----
>         The Activation ID (AID)
> 
> These are strings that tell how to bootstrap a specific object
> instance. This means that environmental information such as hostname,
> user, etc. They have the following format:
> 
> OAFAID:[IID,user,host,domain]
> 
> IID format has been described above. 'user' is the login
> username. 'host' is a DNS domain name or stringified IP
> address. 'domain' is a string describing what use area the object has
> - normally this will be 'user' (XXX not clearly defined yet).
> 
> Manual creation of AIDs is unsupported - instead, just store and use
> the ones returned by the activate() operation.
> -----
> 
> 	  So clearly, you may not contstruct an AID manually. i.e. 'I want
> 	  to activate a specific IID on a specific host'. The only way to
> 	  obtain an AID for a component is through a bonobo-activation query.
> 
> 	  So the most important requirement for remote activation is that
> 	  bonobo-activation be able to bootstrap to bonobo-activation servers
> 	  running as a specific user on other hosts[1].
> 
ok, this makes things clearer for me.

> 	+ It should also be a requirement that the object directories the server
> 	  bootstraps to is configurable at an enterprise, system and user level.
> 	  It strikes me that GConf is intended to allow configuration to be
> 	  manipulated at all these levels, and is the obvious choice for the
> 	  storage of this configuration - but thats an implementation detail.
> 
also added

> 	+ The requirement that the remote component support session management
> 	  is too vague. Is the requirement that remote components should be
> 	  able to connect to the session manager, or that apps launcher by the
> 	  component be able to connect to the session manager or that a
> 	  component be able to participate in session checkpoints with the
> 	  activation server acting as a proxy and the actual re-activation of
> 	  the component when the session restarts is performed by the activation
> 	  server and not the session manager .... ? It should also be a seperate
> 	  section, given that the details of the requirement is expanded.
> 
I'm not sure exactly what the requirements are here, since I added them
after Michael's request, so it's Michael who should specify them.

> 	+ Configuration database requirement: this is that the remote component
> 	  should explicitly made connect to the gconfd on the same host as the
> 	  Xserver, rather than assuming this will work by a shared home dir over
> 	  NFS, right ?
> 
I think the right solution is to use the same GConf database, so yes,
that means connecting (or obtaining a reference) to the local GConf
daemon.

> 	+ 2.4 (optional) Daemon support: this needs to be more detailed, if
> 	  there at all, since it seems more of an implementation detail. How
> 	  can DNS be used to overcome the bootstrapping problem? When you[2]
> 	  say 'by remote ssh based activation' do you mean that the activation
> 	  server is launched using ssh or are you refering to the actual
> 	  activation of the components themselves?
>
ssh activation for the remote activation server, not for the components
themselves, which should be activated by the remote b-a daemon that has
been bootstrapped.

> 	+ 2.5 Client Visibility: I think this requirement could be made more
> 	  general. 'There is plenty of room within the bonobo-activation
> 	  architecture for remote activation support. The implementation
> 	  should address the specific problems (e.g. bootstrapping and the
> 	  physical activation of components) rather than re-architecting.
> 	  For example, the AID should continue to be used as it already
> 	  has holds remote activation semantics.
> 
as for your AID's explanation, I've changed this part also in the GEP.

> 	+ We need to add a 'Security' requirements section with the input
> 	  from Alan. Its very important that secure handshaking and encrypted
> 	  communication is a requirement. If we don't have the former how
> 	  do you know that you're not activating rogue components on a
> 	  different host and if you don't have the latter people may sniff
> 	  the IORs of the component and play havoc with it. It might be good
> 	  for someone with enough knowledge in this domain be added to the
> 	  list of responsible persons.
> 
ok, added this part with Alan's comments.

cheers