Re: GEP 3 - Remote activation in bonobo-activation

[Mark McLoughlin <mark skynet ie>]

Hi Michael,

On 4 Sep 2002, Michael Meeks wrote:

> Hi Mark,
>
> On Tue, 2002-09-03 at 06:13, Mark McLoughlin wrote:
> > 	  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.
>
> 	Yes; the problem is -  that this model is uber-slow, also the current
> implementation does truly incredibly evil things with memory management;
> so I've been trying to exorcise this from the code as much as possible
> [especially since it creates complexity to the point where it's not
> possible to fix the more serious race conditions etc. in there].
>
> 	So this model needs fixing; there is no need for the ObjectDirectory to
> be constantly sending it's entire contents [ not at all small ] over the
> wire per query. If new components are registered - they should trickle
> across the network IMHO, rather than adding the worst case latency to
> the query.

	Oh obviously I was just talking out of my hat and haven't
looked at in close detail :-) Sure the get_servers/get_active_servers
thing looks like something that will kill performance when the
ObjectDirectories aren't local ...

	But what I was getting at, is that assuming we broadly keep
the ActivationContext/ObjectDirectory model (I don't see why not - it
doesn't have to be uber-slow nor implemented in an incredibly evil
manner) we need some way to bootstrap other ObjectDirectories into the
ActivationContext. I'm aware that this is what 2.3 is getting at, but
I think it needs to be more adequetly described ....

> >         The Activation ID (AID)
>
> 	The thing is, that wonderful as the document sounds, we have problems
> getting the right 'FooID' == 'DISPLAY,OAFIID:...' setup and passed
> around, such that I'm highly concerned that we rationalize most of this
> in some sane, and extensible way.

	Sure, its not ideal - fixing that though is outside the scope
of this GEP surely - or do we want to turn it into a
'bonobo-activation needs to be re-designed GEP' :-)

> > 	+ 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.
>
> 	Yes; however - making bonobo-activation depend on gconf does not seem
> at all attractive to me.

	:-) The important part of the paragraph was not that b-a
should depend on GConf, but that the ObjectDirectories b-a-s
bootstraps should be easily configurable in an enterprise scenario
should be made a requirement in the GEP. One shouldn't have to go
fiddling with config files for each host/user if you want to make
available your spanking new repository of applets to everyone on site.

	Now, it strikes me that GConf is supposed to make supporting
this scenario easy - but if its that undesirable to depend on GConf
then we may want to re-implement it in b-a. But whether or not we use
GConf to solve the problem - well, that's an implementation detail and
we're discussing requirements so ...

> > 	+ The requirement that the remote component support session
> >           management is too vague.
>
> 	Not at all; it's a requirement. It also happens to be broken right now
> - I don't want new features added that jepordise the possibility of
> getting this 100% right in the future - and this includes SM. Even if
> it's not a big issue.

	??? I'm saying that "to have the remote activation system
support session management" is far to vague a sentence to be
considered a requirement. I have no idea what the sentance actually
means and I'd like it clarified. I gave a list of things I thought the
sentence *might* mean - but one shouldn't have to guess at the meaning
of a requirement.

> > 	+ 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.
>
> 	Yes - we need to know what we're going to do with ORBit2 and security
> moving forward wrt. SSL etc. Clearly it makes the most sense to foist
> the problem off onto someone else (hopefully) qualified to deal with it.
> That is - if we can find a non-stupidly-license-encumbered SSL library
> somewhere.

	Hmm, sure. So we now have at least two other features that
this GEP depends on in order to satisfy the requirements a) fixing how
AIDs work and b) some sane security features in ORBit2. You could also
probably add c) some sane intergration of components into X session
management and d) support for components that can display on multiple
X displays (using gtk+'s myulti-display support). So is the GEP too
premature ?

Good Luck,
Mark.