Re: Activation: b-a-s problems.

On Thu, 2004-01-08 at 12:12, Mikael Hallendal wrote:
> Hmm .. I was thinking that maybe this shouldn't be handled by the bus
> itself. If you need to have applications that needs to be started again
> with another set of environment variables it can be handled by a factory
> service.

        Now this is getting somewhere; going right back to my initial
contention - my feeling is (and what would I know ;->) that it's best if
the component itself _and not the activator_ grokks the scope of the
activator to determine what should be activated.

        As a rule of thumb; I think a good way to do it is to shove ~a chunk of
the environment from the client into the environment of the 1st time
forked service[1]. Subsequent activations / service fetches from
different clients would then want to again pass their environment.

        What we (are) finally iterating towards in b-a-s is that the component
specifies in the .server file what environment variables it cares about;
but this has it's issues. Another problem is that not all scope
necessarily (current screen eg.) can necessarily be extracted from the
environment in an app that can render to multiple screens, play to
multiple audio devices etc. Either way, as Mark says - many of the worst
problem we suffered are hidden by a per-session daemon.

> This will keep the bus simple as was one of the design goals and also
> gives every app the possibility to override this functionality (ie.
> GConf should only have one daemon running).

        I must admit that (reading b-a) it seems one of the design goals was to
introduce excessive, unwanted / tested / thought-through complexity,
which I'm still trying to get rid of.

        Regards,

                Michael.

[1] - assuming that your activation system is in fact going to cope with
non-live objects that need hydrating from disk.