[rfc] Activating Common Services

[Thiago Macieira]

Richard Hughes said:
[snip]
> Even tho the hald process is successfully started.

Cool. That means your patch is actually working in real environments :-)

> Subsequent dbus methods on LaptopPanel work as expected.
>
> I think the problem is that HAL only adds the devices after it registers
> itself on the bus, so:
>
> sudo killall hald
> dbus-send --system \
> 	--print-reply \
> 	--dest=org.freedesktop.Hal /org/freedesktop/Hal/Manager \
> 	org.freedesktop.Hal.Manager.DeviceExists string:moo
>
> works as expected, and activates the system service.

If you had used qdbus, it could have "hidden" the problem: since it
introspects the target object before making the call, the actual
activation is the introspection. The call itself comes second.

Then again, if the target object doesn't exist yet, the introspection
would have failed too. Which is why I'd like to introduce the
UnknownObject and UnknownInterface errors: you don't know what the case is
here.

> 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.

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.

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

> 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!), 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.

> (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.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358