toabctlstgraber, I recognized that you implemented a dconf bridge for upstart. what's the reason for that?06:00
xnoxtoabctl: https://lists.ubuntu.com/archives/upstart-devel/2012-November/001987.html09:22
toabctlxnox, so user session daemon should be started when a dconf key changes, right?09:25
toabctlthat's a possible usecase?09:25
xnoxtoabctl: no.09:25
xnoxtoabctl: well yes.09:25
xnoxtoabctl: e.g. upstart runs the use session, and user jobs can listen to dconf events and do start on stop on.09:26
xnoxtoabctl: so yes =)))) but it's for any dconf events.09:27
toabctlwhat about other daemons? eg NetworkManager?09:28
toabctlmaybe you want to start a job when NetworkManager sends an event.09:28
toabctleg a firewall script, ...09:28
jodhtoabctl: we already emit net-device-up and net-device-down. See upstart-events(7)09:29
jodhtoabctl: that said, we could expand the variables set in those events to include things like ESSID say.09:29
toabctljodh, but more detailed events. eg "vpn-connected"09:29
jodhtoabctl: please raise a bug so we can consider it09:30
toabctljodh, I don't need this. I just want to get a picture where the border between upstart and other system daemons is09:31
toabctlI guess you could build a bridge between every system daemon and upstart which has something like signals/event and map that to upstart jobs/tasks09:31
jodhtoabctl: 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:32
jodhtoabctl: 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 need09:33
toabctljodh, sounds good.09:34
=== jMCg_ is now known as jMCg
=== broder is now known as broder_

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!