Re: GEP 3 - Remote activation in bonobo-activation
- From: Mark McLoughlin <mark skynet ie>
- To: Rodrigo Moya <rodrigo gnome-db org>
- Cc: gnome-hackers gnome org, <gnome-components-list gnome org>
- Subject: Re: GEP 3 - Remote activation in bonobo-activation
- Date: Tue, 3 Sep 2002 06:13:48 +0100 (IST)
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 :-))
_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]