[06:00] <toabctl> stgraber, I recognized that you implemented a dconf bridge for upstart. what's the reason for that?
[09:22] <xnox> toabctl: https://lists.ubuntu.com/archives/upstart-devel/2012-November/001987.html
[09:25] <toabctl> xnox, so user session daemon should be started when a dconf key changes, right?
[09:25] <toabctl> that's a possible usecase?
[09:25] <xnox> toabctl: no.
[09:25] <xnox> toabctl: well yes.
[09:26] <xnox> toabctl: e.g. upstart runs the use session, and user jobs can listen to dconf events and do start on stop on.
[09:26] <xnox> etc.
[09:27] <toabctl> ok
[09:27] <xnox> toabctl: so yes =)))) but it's for any dconf events.
[09:27] <xnox> s/use/user/
[09:27] <toabctl> sure
[09:28] <toabctl> what about other daemons? eg NetworkManager?
[09:28] <toabctl> maybe you want to start a job when NetworkManager sends an event.
[09:28] <toabctl> eg a firewall script, ...
[09:29] <jodh> toabctl: we already emit net-device-up and net-device-down. See upstart-events(7)
[09:29] <jodh> toabctl: that said, we could expand the variables set in those events to include things like ESSID say.
[09:29] <toabctl> jodh, but more detailed events. eg "vpn-connected"
[09:30] <jodh> toabctl: please raise a bug so we can consider it
[09:31] <toabctl> jodh, I don't need this. I just want to get a picture where the border between upstart and other system daemons is
[09:31] <toabctl> I guess you could build a bridge between every system daemon and upstart which has something like signals/event and map that to upstart jobs/tasks
[09:32] <jodh> toabctl: any system facility is free to emit upstart events. We're trying to add events where appropriate to allow jobs to react in the most efficient manner to system state changes.
[09:33] <jodh> toabctl: yes, but we don't want hundreds of bridges running. We are planning dconf, temporal events (a la cron), inotify events for file changes and a generic dbus bridge would probably give user 99% of what they need
[09:34] <toabctl> jodh, sounds good.