[14:06] <Keybuk> hurrah
[14:06] <Keybuk> after 4 hours of fiddling, I'm now back to being able to make a change :p
[14:42] <Keybuk> http://bazaar.launchpad.net/~keybuk/upstart/trunk/revision/scott%40netsplit.com-20080411134155-1ormw1ojnkh5thqb?start_revid=scott%40netsplit.com-20080411134155-1ormw1ojnkh5thqb
[14:42] <Keybuk> \o/
[14:59] <Keybuk> and with the following revision, we now support respawn and task :)
[14:59] <Keybuk> task
[14:59] <Keybuk> exec /some/script
[14:59] <Keybuk> respawn
[14:59] <Keybuk> will repeat /some/script until it exits with zero :)
[17:02] <ion_> keybuk: Nice
[17:38] <Keybuk> My main blocker at the moment is deciding whether or not to export the difference between Jobs and Instances over D-Bus
[17:38] <Keybuk> and if not, which way to err
[17:46] <Keybuk> ie.
[17:46] <Keybuk> should it have a D-Bus object per job
[17:46] <Keybuk> should it have a D-Bus object per instance
[17:46] <Keybuk> or should it have D-Bus objects for both?
[17:47] <Keybuk> per job would mean you had .../jobs/getty with Start() and Stop() methods, and methods to probe for instance and process information
[17:48] <Keybuk> per instance would mean you had .../jobs/getty-tty1 with a Stop() method; and a Start(name) method on the upstart object
[17:48] <Keybuk> both would mean you had .../jobs/getty with Start() and StopAll() methods, then .../jobs/getty/tty1 with a Stop() method and methods to probe process information
[17:48] <ion_> I’d lean towards the latter, and .../jobs/getty would provide a method to find a list of .../jobs/getty-tty1 etc.
[17:49] <ion_> My thinking tends to favor object-orientation.
[17:50] <Keybuk> the only real problem with the latter I guess is the overhead in terms of D-Bus objects
[17:50] <Keybuk> Job.Start(Array of String env)
[17:50] <Keybuk> job.GetInstance(Array of String env)
[17:50] <Keybuk> job.GetInstanceByName(String name)
[17:50] <Keybuk> something like that?
[17:51] <ion_> But is that overhead really that big?
[17:51] <Keybuk> maybe not I guess
[17:51] <Keybuk> Job.Start(Array of String env) => (Object Path instance)
[17:52] <Keybuk> Job.GetInstanceByName(String name)
[17:52] <Keybuk> Job.GetInstanceByEnv(Array of String env)
[17:52] <Keybuk> (all => instance)
[17:52] <Keybuk> Job.StopAll(Array of String env)
[17:52] <Keybuk> Instance.Stop(Array of String env)
[17:52] <Keybuk> Instance.Restart()
[17:53] <ion_> Looks nice.
[17:53] <Keybuk> Manager.GetJobByName(String name)
[18:15] <Keybuk> I guess that'd mean I could throw away instance ids :p
[18:15] <Keybuk> UPSTART_JOB=getty
[18:15] <Keybuk> UPSTART_INSTANCE=tty1
[18:15] <Keybuk> would be enough :p
[18:15] <ion_> How would that go currently?
[18:16] <Keybuk> right how you'd have
[18:16] <Keybuk> UPSTART_JOB=getty
[18:16] <Keybuk> UPSTART_JOB_ID=3721
[18:16] <Keybuk> where initctl would only use the latter
[18:16] <Keybuk> if I dropped ids, initctl would use both
[18:16] <Keybuk> Manager.GetJobByName($UPSTART_JOB).GetInstanceByName($UPSTART_INSTANCE).Stop() :p
[18:17] <ion_> Nice
[18:17] <Keybuk> "start" would become an error in a job
[18:18] <Keybuk> with "restart" being the right command
[18:18] <Keybuk> ie.
[18:18] <Keybuk> pre-stop script
[18:18] <Keybuk>   [ ... ] || restart
[18:18] <Keybuk> end script
[18:18] <Keybuk> ?
[18:18] <Keybuk> hmm
[18:18] <Keybuk> maybe they should still be different
[18:18] <Keybuk> start returns you to start without killing
[18:18] <Keybuk> restart would kill, but return you back to start again
[18:20] <ion_> Any use cases?
[18:21] <Keybuk> just thinking of things being common senes
[18:21] <Keybuk> there's a few obvious ones
[18:21] <Keybuk> stop on stopping some-other-job
[18:21] <Keybuk> pre-stop script
[18:21] <Keybuk>   if can-carry-on-with-it-but-need-restart; then
[18:21] <Keybuk>     restart
[18:21] <Keybuk>   fi
[18:22] <Keybuk>   if can-ignore-it-safely; then
[18:22] <Keybuk>     start
[18:22] <Keybuk>   fi
[18:22] <Keybuk> end script
[18:22] <ion_> Perhaps start should be named otherwise to avoid confusion, though.
[18:25] <Keybuk> such as?
[18:29] <ion_> I dunno. cancel-stop? :-P
[19:35] <Keybuk> ion_: that'd mean a /usr/bin/cancel-stop? :p
[19:41] <ion_> Well, it would, and that would suck. :-P
[19:42] <Keybuk> heh