Re: GEP 3 - Remote activation in bonobo-activation

[Michael Meeks <michael ximian com>]

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.

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

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

	Then again - I want b-a-s to do session management for it's children,
which implies an X dependency; so we're going to have to plug that in
somehow from higher up the stack. Indeed, in my ideal world I'd like to
fold bonobo-activation into the 'libbonobo' module, so we can use
BonoboObject, cleanup the codebase, reduce the module count etc.

	I don't believe there is any project that just uses bonobo-activation
currently. [ Java / pure IDL useage aside - it's pretty trivial to split
out Bonobo_Unknown if you're that worried ].

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

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

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot