[rfc] move activation to a helper process

[Havoc Pennington]

David Zeuthen wrote:
> On Thu, 2006-10-19 at 18:48 -0400, Havoc Pennington wrote:
>> What I meant by "system directory" is "one of the service file 
>> directories listed in system.conf" - in fact, maybe we don't need to 
>> check owned by root if you think that will cause problems - if you make 
>> the service file directory writable by users, I guess it's probably your 
>> own fault... maybe it's even useful in some scenarios to let certain 
>> groups write to one of these directories.
> 
> Yeah. I think so too. Driving home tonight I remembered how jhbuild
> works; IIRC some (most?) people install to /opt/gnome2 where /opt/gnome2
> normally is owned by non-root, e.g. the user that builds it. 
> 
> So, the crux of the problem is that any included .conf file can include
> <servicedir> plus the user might change system.conf. So essentially we
> need to watch for a) the system.conf configuration file changing; and b)
> all the directories in <includedir>. Which brings us back to parsing the
> entire configuration at least. We could cache this and watch for
> configuration file changes. Does that sound reasonable? 
> 

I think this is good. Caching/watching the config isn't even needed for 
the moment; that should not make a lot of structural difference. Passing 
around .service filenames seems like a larger change so more worth 
getting right in the beginning. It also makes a (small) semantic 
difference to apps.

>> It'd be nice to stick 1.0 in an FC6 update though, so maybe we should 
>> really try to stick to a freeze.
> 
> Yeah, well, uh, I dunno. I'd like the feature to get in 1.0 mostly so
> because I think people would expect it to be there. I'm also not sure
> rushing things for something as fundamental as D-Bus is a good idea
> either. Then again, the buck needs to stop somewhere. But, sure, putting
> the patch in D-Bus 1.1.0 [1] or whatever is feasible too, it just feels
> weird to put a major feature in an update release. Plus that release
> might not come out for some time as other feature development is
> ongoing.

I'm not sure we'll get accused of rushing dbus ;-)

I don't have strong feelings here. I think we probably need another RC 
anyway, since there are some other changes. But on the other hand, 
really testing system activation will take a while - it involves also 
coding a few of the use-cases and getting them in a devel distribution 
someone is using... I don't think it would hurt to basically do this in 
rawhide. We can do 1.2 pretty quickly if necessary. Maybe it could be 
system activation + win32 port.

I'm hoping there isn't much other feature development to be honest. I'm 
guessing pretty much everything from now on is going to be feature creep 
and bloat, so I'll try to drag my feet and whine about all features and 
hopefully that will at least mean it'll take a few years before things 
get disastrously overbloated ;-)

For most stuff, the effort at this point would be much better spent on 
the bindings than the dbus core imo...

> [1] : I'm not sure how versioning is going to work post 1.0, perhaps
> it's a good idea that 1.<odd> are development releases and 1.<even> are
> stable releases. Dunno

I'd like to do this.

> (FWIW, I'm going to stick this patch in FC7 D-Bus when that opens next
> week and some bits that I and others are working on will start depending
> on D-Bus + system bus activation patch. So in that respect getting the
> patch in 1.0 might be of benefit to other distributions if they want to
> use those bits.)

It would make sense to me to do this for a couple months or so before 
declaring system bus activation stable - whether that means delaying 1.0 
another couple months or doing 1.2 in a few months, I could go either way.

I would say the version numbers are mostly cosmetic at this stage; we 
have strong reason to believe the ABI won't change, and strong 
motivation not to change it, and so all the versions would really 
reflect is whether there's been a freeze-and-test period.

I guess that's an argument for holding to this freeze, get a release 
out, then do a 1.2 followon ideally within 3-4 months.

Havoc