Time-Shift: Veritas liberabit vos
The truth shall set you free

Posts Tagged ‘KWatchman’

KWatchman – An Idea given Birth

Tuesday, October 12th, 2010

First of all: Thank you everyone for you comments and suggestions. They really got me on the road and showed my that there indeed is interest enough to do some more serious work. So I sat down and made myself a little planing and even some (small) coding today. Here’s what I got so far:

The project will consist of mainly 3 Parts:

  1. Part one being the kwatchman-service (in what manner I’ll realize this I’m not sure yet). Its basically just an empty rack to manage and run part 2 (maybe this will even be a daemon so it can run under higher privileges).
  2. Part two being Plug-ins that can be loaded by kwatchman-service. There will be (for now) 4 kinds of Plug-ins:
    • Sensor Plug-ins (they collect the data from a specific source e.g. libsensors-plugin, hddtemp-plugin, nvclock-plugin, etc.. )
    • Interface Plug-ins (they provide interfaces for all apps that like to access the collected data e.g. dbus-plugin, network-plugin, nagios-plugin?, etc… )
    • Database Plug-ins (they provide storage for long term data collection e.g. mysql-plugin, postgresql-plugin, nepomuk-plugin?, etc… )
    • Alert Plug-ins (they do something in case an alert is issued by crossing some threshold e.g. knotify-plugin, phonon-lugin, log-plugin, shell-plugin, etc… )

Apart from the database Plug-ins all Plug-ins can be used or not used at will. So the user can ultimately decide what gets refresh and which alert is being send if a threshold is crossed. Concerning the Database Plug-ins I guess its much easier if only one is allowed at a time. All other use cases can be handled by Interface Plug-ins (e.g. if you want nepomuk as your db but want to access the data via php on a webserver a php friendly interface Plug-in would be the solution).

  1. The last part are GUI’s that access the data and configure the Plug-ins via the interface Plug-ins. Those can be a very wide variety of apps and applets ( e.g. native KDE4 apps, plasmoids, KCModules etc.). Im not completely sure how the initial configuration of the service should be made so that at least the correct interface Plug-in for your favorite App is activated.

The first implementation will (most likely) contain:

  • The kwatchman-service (whatever it will be)
  • A lm_sensors sensor Plug-in
  • A nepomuk or MySQL database Plug-in (not sure yet)
  • A native (ksensors like) KDE4 app
  • A interface Plug-in for the native app (maybe via dbus?)
  • A knotify Alert Plug-in

As soon as I’ve got those components in working order I’ll concentrate on more sensors and Alert Plug-ins. After I that database Plug-ins will be my attention and finally I’ll write some more apps and Interface Plug-ins.

As for now I’ve got a (very rudimentary) cmake concept for detecting libs and deciding what gets compiled, a (also rudimentary) file structure for the code and some template for the KDE4 App.

So.. now to it: What do you think about THAT concept? Crazy? To big? Super? If you have any supplementary suggestions to the concept don’t hesitate to comment!