Activation: b-a-s problems.

[Mark McLoughlin]

Hey,
	(Sorry for being so late to this discussion)

	One thing to bear in mind when looking at how we did this in
bonobo-activation is that bonobo-activation makes life very difficult
for itself by being a per-user system-wide daemon. Most of the really
horrible problems we were seeing with bonobo-activation goes away when
you start activating services through a per-session bus. If you're
activating a service through a system-wide bus, the context of the
client and the context of the bus are more likely to be very different.

	One example of that is on Sun Ray, where you can have multiple
sessions, all on different displays, each session has a different audio
device. We were seeing things like the mixer applet controlling the
audio device of the wrong session because the applet was being launched
with the wrong AUDIODEV - i.e user logs in at one terminal, goes into a
meeting and logs in (actually starts another session) at another
terminal and finds his mixer applet is controlling the volume of his
first session.

	So, as people have already said, with the per-desktop bus there are
only really two issues:

  - Multi-screen setups:

	If a client on screen 1 activates a service and it has already been
activated on screen 0, the client only wants that first instance of the
service (the one on screen 0) if the service has explicit support for
displaying on multiple screens simultaneously.

	gnome-terminal can't do this, whereas nautilus can i.e.

DISPLAY=:0.0 gnome-terminal
DISPLAY=:0.1 gnome-terminal

DISPLAY=:0.0 nautilus
DISPLAY=:0.1 nautilus

	gnome-terminal will start 2 processes, nautilus will only start one.

	So, AFAICS, we can either allow individual services to mandate whether
there must be an instance of the service for each screen or we can
require that services are always per-screen whether they can support
multiple screens or not.


  - Multiple languages

	If a client running under language A activates a service and it has
already been activated under language B, we always want a new instance
of the service running under language B ... assuming that the service
provided is actually language specific and/or it cannot provide that
service for multiple languages.

	At first glance, it might seem like per-language service activation is
the right way to go, but we do have at least one example of service that
can serve multiple languages - gconfd. So:

LANG=en_US clock
LANG=en_GB clock

	should not cause two gconfds to be started, but rather gconfd will
correctly hand out the default value for the "hour_format" preference in
both cases (i.e. 12-hour in en_US and 24-hour in en_GB).

	On the other hand, if you do:

LANG=en_US gnome-terminal
LANG=en_GB gnome-terminal

	there should be two gnome-terminal processes - one which lets you
configure the terminal "colors" and the other which (correctly) lets you
configure the terminal "colours".


	In summary:

  + The use cases are probably limited to very specific cases
  + Some services will depend on the activating clients context
  + Only the service itself can know whether it depends on the clients 
    context

Cheers,
Mark.