| 1 |
Hi all, |
| 2 |
|
| 3 |
Here is the proposal for an event based framework for scire. I wrote |
| 4 |
it as part of the SoC program. |
| 5 |
|
| 6 |
Regards |
| 7 |
|
| 8 |
|
| 9 |
Scire's event framework proposal |
| 10 |
------------------------------- |
| 11 |
|
| 12 |
Author: Rodrigo Lazo |
| 13 |
Time-stamp: "2007-08-20 12:53:27" |
| 14 |
|
| 15 |
Abstract |
| 16 |
------- |
| 17 |
|
| 18 |
SCIRE aims to "create a widely extensible common portal for |
| 19 |
administrative tasks for multiple Linux client machines"[1]. To be |
| 20 |
able to achive this extensibility goal, SCIRE must provide some entry |
| 21 |
points for the third-party extensions. We propose that the backend |
| 22 |
entry points were event-based. Scire's core will provide some "hooks" |
| 23 |
for the important events (e.g pre-client-creation-hook, |
| 24 |
post-job-modification-status-hook). |
| 25 |
|
| 26 |
Detailed Proposal |
| 27 |
----------------- |
| 28 |
|
| 29 |
The event-based method to extend an application is used for example on |
| 30 |
the netfilter project ("netfilter is a set of hooks inside the Linux |
| 31 |
kernel that allows kernel modules to register callback functions with |
| 32 |
the network stack."[2]), Emacs (""Hooks" are an important mechanism |
| 33 |
for customization of Emacs. A hook is a Lisp variable which holds a |
| 34 |
list of functions, to be called on some well-defined occasion."[3]) |
| 35 |
and so on. |
| 36 |
|
| 37 |
Scire has some features that could be called to be part of "the core" |
| 38 |
system, and they include, but under no means are restrict to: client |
| 39 |
(individual and groupal) management, profiles management and job |
| 40 |
management (including scripts). Using event-based hooks could allow |
| 41 |
some nice features without affecting the core system (that by all |
| 42 |
means should stay as minimal and clean as possible to avoid security |
| 43 |
problems and to reduce maintenance overheat. Here an example: |
| 44 |
|
| 45 |
Sample adding Client routine: |
| 46 |
|
| 47 |
V |
| 48 |
| Pre-client-add-hook |
| 49 |
+----------------------------o (send a sms to the scire root) |
| 50 |
| |
| 51 |
+-------o---------+ client-add-hook |
| 52 |
| Client add -------------------o (logging on a third party module) |
| 53 |
| Mechanism | |
| 54 |
+-------+---------+ |
| 55 |
| Post-client-add-hook |
| 56 |
+----------------------------o (create a job to gather client info) |
| 57 |
| |
| 58 |
= |
| 59 |
|
| 60 |
All the modules to interact dinamically could be loaded and unloaded |
| 61 |
for the system while running, achiving a more stable system. |
| 62 |
|
| 63 |
Implementation Problems |
| 64 |
---------------------- |
| 65 |
|
| 66 |
Right now the scire code is splitted. The backend, written on Python, |
| 67 |
implements basically the communication between the client and the |
| 68 |
server; the frontend, written on PHP, interacts with the user. The |
| 69 |
difficult lies on creating a unified event-based system that could |
| 70 |
react to events launched by any of the two enviroments (e.g. when a |
| 71 |
client fails it could be detected by the backend, but the users |
| 72 |
resolution of the problem is only detected by the frontend). |
| 73 |
|
| 74 |
Proposed Modules to make use of this mechanism |
| 75 |
----------------------------------------------- |
| 76 |
* Successful Job's reschedule |
| 77 |
* Logging module |
| 78 |
* User notification module (sms, e-mail) |
| 79 |
* Job output postprocessing |
| 80 |
* etc |
| 81 |
|
| 82 |
-- |
| 83 |
|
| 84 |
Rodrigo Lazo (rlazo) |
| 85 |
-- |
| 86 |
gentoo-scire@g.o mailing list |
Archives