[rfc] Activating Common Services

[Havoc Pennington]

Hi,

Richard Hughes wrote:
> 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),
> 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

Remember not to use 'activation' in APIs ;-)

There is a StartServiceByName call already, and many can be stopped by 
just taking their bus name (use REPLACE_EXISTING flag).

In general life cycle policies are service-dependent since the best 
policy will vary. Some good options include:

  - stop after a timeout of inactivity. next time a client
    tries to use the service, allow activation to kick in
  - keep track of which clients are using the service and
    watch NameOwnerChanged to see when they come and go
    on the bus; exit if no clients remain
  - just run forever

The life cycle of particular objects offered by the service need not 
match the entire service, e.g. there can be objects that are "allocated" 
and "freed" by clients, as long as the service auto-frees everything if 
the client disconnects.

> 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. 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).
> 
> (ignoring the fact we have stale refcounts if the bluetooth file
> transfer program crashes...)

This is very key not to ignore ;-) in fact it's so critical that you are 
better off just not messing with refcounts. Distributed refcounting is 
both slow and unreliable.

Since the service has to monitor the client anyway to see when/if it 
disconnects, it should just monitor the client - "self-refcounting" you 
might say.

I think it works pretty well to have objects with explicit alloc/free 
type of calls, where the free happens automatically if the client 
disconnects. Then a client can help the service free things sooner, but 
the service doesn't really rely on it.

I would suggest alloc/free on particular objects in the service API 
rather than on the entire service, since a service API can in principle 
grow arbitrarily complex. The "one bus name, one interface, one object" 
pattern that leads people to ask why they are typing the same thing 
three times is not the only possible pattern.

Havoc