hughsient at gmail.com
Tue Dec 11 13:45:55 PST 2007
On Tue, 2007-12-11 at 21:08 +0000, Scott James Remnant wrote:
> Upstart suffered from a strange effect of open source; I sent out lots
> of early thoughts on the design, and didn't really get much buy-in
> because there wasn't any code. But when I went away and wrote the code,
> now nobody was interested in it because there was "too much code!" --
> it's too difficult to swallow in one pill.
Agree. I went with completely open criticism along with blogging with
ideas for PackageKit, followed closely with a semi-working code drop.
It's a tricky one.
> That's where I hope you guys will come in, by getting different people
> from different groups involved early on. Also checking my work and
> helping make some decisions :-)
Cool, thanks for the CC.
> First up: terminology. What do we call what InitKit manages?
> "service" is obvious, but has connotations of supervision; it also
> overlaps with "D-Bus Service Activation" which is likely to scare that
> group into believing we're trying to replace D-Bus instead of use it
Service is a good name, but as you say, overlaps with DBUS just too
> "task" has the opposite problem, it implies it's a one-off thing that
> doesn't stay around or get supervised.
Task to me is a single shot action.
> "job" is a bit simple, everything in UNIX ends up being a job.
Again, single shot.
> "script" implies it's written in shell, which daemons mostly aren't
> "daemon" implies it forks into the background, which ideally they
> "process" says it's just one thing, but it might be several
> I find some amusing words in a Thesaurus: "duty", "chore", "stint" :-)
Why not make one up? Seriously! What about ManagedService?
> bus name: org.freedesktop.Init
> object: /org/freedesktop/Init
> interface: org.freedesktop.Init
Rock on with this IMO.
> What about the method form?
> Start (String service_name)
> Stop (String service_name)
> Or do we build for extension?
> FindServiceByName (String name)
> which returns an object that implements org.freedesktop.Service, which
> has the following methods:
> Start ()
> Stop ()
Nahh, too much like DBUS. We'll know what to start and stop surely?
> Obviously in either case, the call should return when the service is
> running or stopped, or return an error.
Sure. I'm sure this open development will be good politically, even if
we end up using whole swathes of upstart code. :-)
More information about the InitKit