[ohm] OHM vs. PPM
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
More information about the Ohm-devel