[ohm] OHM vs. PPM

Marc-André Lureau marcandre.lureau at gmail.com
Sat May 3 04:08:08 PDT 2008


On Fri, May 2, 2008 at 1:16 PM, Rob Taylor <rob.taylor at codethink.co.uk> wrote:
> Marcel Holtmann wrote:
>  >       client creates object
>  >       client call RegisterAgent(object) on the server
>  >
>  > After that the server knows the unique name of the agent/client since it
>  > comes via the message. It also knows the object path of the clients
>  > objects. The only common factor is the interface definition to be used
>  > on that specific object. The server can also monitor the
>  > NameOwnerChanged signal to see if the client dies unexpected.
>  >
>  > For all requests that need user interaction, the server can now call
>  > into the interface from the agent.
>  >
>  > This gives the perfect system level versus user session separation
>  > without playing any dirty tricks or having static bus names or object
>  > paths.
>  That sounds like a very nice pattern, I'll keep it in mind.

I don't see what is special about this pattern. I have seen it
implemented several times, when a service needs to know and monitor
it's client. That's quite standard.

Now, from the system bus, how do you deal with multiple user and
fast-user switching? Do you use ConsoleKit for example, to send
request to the active user only?

For the policy decision, I don't think it's a good idea to have to run
a small daemon in the system level and several session agent. I would
just get rid of the system agent and use hal/policykit to deal
correctly with requests and mechanisms (enforcement points) and ACL.
That way, we have less chance to make the system level unstable.

I tend to think that the system level should behave with services like
the kernel behave with the hardware: ensuring that the system stays
stable and offer the access to the lower level bits: decisions are
taken in this level to implement reliability, and performance.
Otherwise, I can think only of hacks to make the system level
context-aware. However, that often make sense for the reliability and
performance reasons.

Marc-André Lureau

More information about the Ohm-devel mailing list