Comment 2 for bug 1185565

Again, I think having processes in the session be aware of the init process (and even depending on a specific implementation) is upside-down architecture.

Also, it has several practical issues:

* it creates a lot of extra work that seems unnecessary, like adding upstart scripts to every indicator service
* everything that consumes indicator menus must emit that upstart signal, instead of simply hitting up the bus names
* it makes it impossible to run indicators or unity on non-upstart systems
* it always starts all indicators for every profile, instead of only loading the ones that are needed
* it makes it impossible to activate an indicator service with an action (admittedly not really a problem as the services are running all of the time under this proposed scheme, and we're not doing this yet)
* it removes the possibility for an indicator service to quit when it is not needed anymore

There are only two benefits that I've heard of: that it is easier for developers to start and stop services, and that logging is split into different files. I think both of these are minor issues that can be solved without direct upstart integration. But even if people think these are important enough, putting upstart in charge of dbus activation gives us exactly the same benefits, without any of the problems I mentioned above.

As an aside, the signal name "indicators-ready" is misleading, because it is not used to signal that indicators are ready, but that they can now be started ("panel-ready" might be better).