Tracking users/sessions on the console

[David Zeuthen]

On Jan 13, 2006, at 6:30 AM, Daniel P. Berrange wrote:
>> I don't think this is necessary nor desirable (just ask the NM  
>> folks how
>> painful it is) for e.g. networking, power management, the screen  
>> saver,
>> volume management and so on. It's so much easier just having a single
>> process, look at e.g. g-v-m and g-p-m and how simple these daemons  
>> are.
>
> I don't buy this argument at all.

Suggest to then e.g. look at the source code for g-p-m and g-v-m.

> When writing GUI applications it is always good practice to  
> separate the
> application model / 'business' logic from the UI display / controller.
> This in turn implies that there is a well-defined API for the UI to
> interact with the application model. Once you have such an API, it  
> will
> be no more difficult for the UI to access the API via direct local  
> library
> calls, or via DBus proxy calls. If it is more difficult, then this  
> is a
> failing in the design/ quality of the DBUs language bindings. The  
> process
> for *applying* system policy for network/power management /screen  
> saver
> can & should be totally independant of the process providing UI for
> *defining* the policy.

I think you're misunderstanding something here.

> I have written two non-trivial applications where the control UI was
> completely separate from the application logic process, client in  
> Python
> and GTK, service in Perl, communicating over DBus. In both cases I  
> think
> the resulting code was much better than what would have resulted if  
> I had,
> had it all in one process - the separation of model from UI really  
> forces
> you to think about application design & provide a well define API.

Let's look at gnome-volume-manager for example. The UI is defined in the
program gnome-volume-properties; this just changes gconf keys through a
GTK+ UI. The program gnome-volume-manager reads these keys and
enforces policy. The latter program have almost no UI except that it  
might
prompt the user to e.g. import his photos. Specifically, if you  
really wanted
you could compile a version of the gnome-volume-manager program
with all the UI bits #ifdef'ed out and it wouldn't even pull in GTK+,  
only
things like gconf.

Now, assume the framework I'm proposing, then the gnome-volume-manager
program would run when no one is logged in with the only change that it
would pop up dialogs. It would still read settings from gconf albeit  
as user
nobody and it would thus get the system defaults.

Please explain exactly what's wrong with this and what changes are
necessary. Surely you're not suggesting to split gnome-volume-manager
into two programs where one uploads policy to the other just for the  
sake
of getting rid of a gconf dependency?!?

> There were some painful times in creating these apps, but they were  
> either
> a result of limitations in the DBus language bindings, or holes in my
> knowledge of writing Python/GTK app. Both of these issues are easily
> resolved, the fundamental model of separating the processes proved  
> very
> effective.

No one yet really commented on the specific change I've proposed for  
D-BUS,
e.g. introducing the ConsoleTracker service.

David