Tracking users/sessions on the console

[Daniel P. Berrange]

On Thu, Jan 12, 2006 at 05:24:52PM -0500, David Zeuthen wrote:
> On Thu, 2006-01-12 at 12:05 -0800, Artem Kachitchkine wrote:
> > As an example, 
> > assume a case of three console users: one running GNOME, another running 
> > KDE and yet another running CDE. It seems to me that under the system 
> > scope things are done a bit differently, and that desktop policy engines 
> > should be system-aware, not the other way around.

I agree, policy engine should be separate from the control UI.

> I read "being system-aware" as it implies a split into two daemons 1) UI
> bits; and 2) system bits much like NetworkManager. Correct?
> 
> 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.

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 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. 

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. 

Regards,
Dan.
-- 
|=-            GPG key: http://www.berrange.com/~dan/gpgkey.txt       -=|
|=-       Perl modules: http://search.cpan.org/~danberr/              -=|
|=-           Projects: http://freshmeat.net/~danielpb/               -=|
|=-   berrange at redhat.com  -  Daniel Berrange  -  dan at berrange.com    -=|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/dbus/attachments/20060113/4ef98642/attachment-0001.pgp