Re: GEP 3 - Remote activation in bonobo-activation

[Mark McLoughlin <mark skynet ie>]

Hi Rodrigo,

	cc-ing gnome-components-list as that is suposed to be the
discussion list ...

On 30 Aug 2002, Rodrigo Moya 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.

	  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].

	+ 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.

	+ 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.

	+ 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 ?

	+ 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?

	+ 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.

	+ 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.


	Btw Rodrigo, thanks for getting this discussion started ...

	Oh good god, did I type all that ? hmmmm :-)

Good Luck,
Mark.

[1] - I'm assuming this is what '2.3 Ease of Activation' is about, but it
      needs a lot more clarification of exactly what the requirement is.

[2] - When I say 'you', I mean whoever wrote it ... Michael may have wrote this
      part - I'm not sure :-))