Re: initial patch for #86016

[Mark McLoughlin <mark skynet ie>]

Hi Michael,

On 15 Oct 2002, Michael Meeks wrote:

> Hi Mark,
>
> On Tue, 2002-10-15 at 08:26, Mark McLoughlin wrote:
> > 	Sure, no problem. What I generally do with patches like this
> > is apply the patch and read the patch and the patched source together.
>
> 	Sorry - being lazy / confidant. I'm happy for the code to go to HEAD -
> simply because it improves so much of this broken mess that I'm happy to
> live with the consequences - at least for now.

	So commit to HEAD and we'll fix later ?

> > But if a branch suits you better ... its on the "activation-env"
> > branch.
>
> 	Ok - I read some more:
>
> 	I'm not so convinced that there is a useful distinction between 'unset'
> and ''; but I suppose there's no harm in having it, it seems strange
> that it's not used in bonobo_activation_setenv - and that this method
> takes 2 strings, instead of 1 pointer to the CORBA structure.

	Sure, I'm not convinced about it either. It was one of the
things that I had planned re-considering - but I don't really have
time at the moment.

> 	In many ways I'd like to try and farm off some of the complexity -
> particularly multi-display stuff to client-land - perhaps passing the
> array of arguments to the Factory interface - [ and do some nasty binary
> hack to the generic factory method ]. Then again this doesn't solve a
> number of problems - such as forking new apps to overcome single i18n
> contexts etc.

	Oh, there's another thing ! Damn, my minds a seive.

	With the current setup there's no way of doing a multi-display
(or multi anything) factory. I had planned on doing that by passing
the passing the arguments to createFactory, but didn't becaus eI
couldn't see an easy way around the ABI problems ... Another thing for
the TODO list :-)

> 	Of course - I still think long term with the SESSION_MANAGER mess we
> need to implement a SM proxy inside b-a-s.

	I'm still not sure what you're hoping to achieve by that. Are
you envisaging that components would be able to take part in a session
checkpoint or ... ? If not, then I don't see what's wrong with just
having out of proc components not connect to the session manager at
all. You can do that with some DONT_CONNECT_TO_THE_SM arg to
gnome_program_init - you don't have to unset SESSION_MANAGER and end
up preventing children from connecting as well.

> One of the serious issues
> that we perhaps havn't taken on-board conceptually - is that some
> applications [ eg. evolution ] use b-a-s for locking - ie. to ensure
> that only 1 evolution is poking at the data at the backend. Clearly -
> it'd be nice to have that split out into a separate daemon and
> communicate via CORBA - but that's not there yet.

	Oh right - well that's broken - right ?

> 	So - the thing is that it's trivial to run two evolution's with
> different SESSION_MANAGERs - happens all the time; whether that's a
> reasonable thing or not I don't know.

	Well, if whatever is poking at the backend isn't interested in
SESSION_MANAGER, nor does it launch any children that may want to be
session managed, then the backend poking thingy doesn't have to be
launched per SESSION_MANAGER.

> 	Grief - having written all this I thought I'd CC gcl so it's archived
> :-) Hope that's ok.
>
> 	I forget why we needed to extend the AID spec ? what was the purpose
> behind that ? was it for querying for currently running components ? -
> if so, I tend to think that's mostly a waste of time.

	Well, the idea behind returning an aid from activate() is that
you can use that AID when calling activate_from_id and get the same
object (if it still exists) or a new object activated the same way. I
think we have to keep ensuring this.

Good Luck,
Mark.