[06:00] stgraber, I recognized that you implemented a dconf bridge for upstart. what's the reason for that? [09:22] toabctl: https://lists.ubuntu.com/archives/upstart-devel/2012-November/001987.html [09:25] xnox, so user session daemon should be started when a dconf key changes, right? [09:25] that's a possible usecase? [09:25] toabctl: no. [09:25] toabctl: well yes. [09:26] toabctl: e.g. upstart runs the use session, and user jobs can listen to dconf events and do start on stop on. [09:26] etc. [09:27] ok [09:27] toabctl: so yes =)))) but it's for any dconf events. [09:27] s/use/user/ [09:27] sure [09:28] what about other daemons? eg NetworkManager? [09:28] maybe you want to start a job when NetworkManager sends an event. [09:28] eg a firewall script, ... [09:29] toabctl: we already emit net-device-up and net-device-down. See upstart-events(7) [09:29] toabctl: that said, we could expand the variables set in those events to include things like ESSID say. [09:29] jodh, but more detailed events. eg "vpn-connected" [09:30] toabctl: please raise a bug so we can consider it [09:31] 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] 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] 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] 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] jodh, sounds good. === jMCg_ is now known as jMCg === broder is now known as broder_