[rfc] Activating Common Services

[Richard Hughes]

On Tue, 2007-06-19 at 15:03 +0200, Thiago Macieira wrote:
> Richard Hughes said:
> [snip]
> > Even tho the hald process is successfully started.
> 
> Cool. That means your patch is actually working in real environments :-)

Yes, totally. I still need to sit down and add unit tests but
essentially the patch works. I'm using it now :-)

> Then again, if the target object doesn't exist yet, the introspection
> would have failed too.

This is the case.

> > So, is HAL wrong to register itself on the bus before adding all the
> > coldplug devices (other services like NM do similar things to this too),
> 
> No, I don't think HAL is wrong. HAL wasn't designed to be auto-activated,
> so it's technically your problem to solve, not HAL's.

Yes, although if we can change HAL trivially (I think we can) then I
guess it might be the "best" solution long term.

> If HAL is made to support auto-activation, then it has to make sure it can
> handle most if not all calls in the first D-Bus message it processes.

Agree.

> That is true of any auto-activated service, on either bus.

Sure.

> > or should we have some sort of "activation" interface that is always
> > present as soon as the service appears on the bus and also lets us shut
> > a service down:
> >
> > org.freedesktop.Hal.Activation.Start
> > org.freedesktop.Hal.Activation.Stop
> >
> > This would be called by the first session application that wants to
> > cause the service to be activated, and also let the service know when
> > it's finished.
> 
> I didn't understand this proposal.
> 
> > For instance bluetooth transfer software for GNOME could
> > ask the bluetooth service to start, raising the refcount by one. When
> > files are finished copying, the Stop method can be called, and if the
> > refcount is zero then the system service can unload itself (also
> > disconnecting from the hardware in the process).
> 
> That's probably that should be handled on a case-by-case basis. Some
> services should be activated on boot (like HAL!)

HAL's not needed until NetworkManager starts, and NM is not needed until
nm-applet is loaded. That's a trivial case, but you get the idea.

> , whereas some others
> could delay initialisation. It probably depends on the reason why it's
> initialisation is delayed: is it to allow a faster boot sequence? Or is it
> because of a resource that shouldn't be hogged (for instance, memory)?
> 
> If it's the problem is the load time, I'd say the service shouldn't unload
> itself: it'll only cause *more* wait the next time around.

Sure, that's probably a important point.

> > (ignoring the fact we have stale refcounts if the bluetooth file
> > transfer program crashes...)
> 
> You can catch a program's disconnection and drop the refcount.
> 
> The problem is if the client program freezes instead of crashing.

Sure. Thanks for your help,

Richard.