[ohm] OHM vs. PPM

[Marcel Holtmann]

Hi Holger,

> > > OHM needs some work before its usable on a desktop system, mainly in 
> > > that it should become a session daemon rather than a system daemon - 
> > > connecting up to X from the system is not ideal.
> > 
> > why? Leave it as system daemon and have an "agent" running in the X
> > session that OHM can refer requests to. You might wanna check out on how
> > BlueZ does it with PIN requests and mode change confirmations.
> 
> These two sentences are too short for getting a complete overview about
> the BlueZ way of doing these things, but this sounds like what we already
> had with the powersave daemon and kpowersave (the time kpowersave was only
> a client for powersaved).

this needs a lot more explaining, but the beauty with the solution that
BLueZ uses is that you don't need any extra well known names for the
applet running in the user session. Even the actual object path is fully
dynamic and then indeed allows to have multiple or stacked agents.

It works like this:

	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.

Regards

Marcel