author | viric <viriketo@gmail.com> |
Wed, 19 Oct 2016 22:08:34 +0200 | |
changeset 349 | 3916245a60b5 |
parent 165 | 7b914d4003c2 |
permissions | -rw-r--r-- |
165
7b914d4003c2
Fixing licenses in some files, and updating some documents.
viric@mandarina
parents:
0
diff
changeset
|
1 |
Introduction |
7b914d4003c2
Fixing licenses in some files, and updating some documents.
viric@mandarina
parents:
0
diff
changeset
|
2 |
--------------------------- |
7b914d4003c2
Fixing licenses in some files, and updating some documents.
viric@mandarina
parents:
0
diff
changeset
|
3 |
This file was written before even the first implementation of 'ts', |
7b914d4003c2
Fixing licenses in some files, and updating some documents.
viric@mandarina
parents:
0
diff
changeset
|
4 |
and it's kept in the repository for historical reasons. |
7b914d4003c2
Fixing licenses in some files, and updating some documents.
viric@mandarina
parents:
0
diff
changeset
|
5 |
|
0 | 6 |
Tool objectives |
7 |
--------------------------- |
|
8 |
- Be able to send commands to the computer, so that they run one after another, |
|
9 |
stored in a queue. |
|
10 |
- Control what to do with the input/output of those programs |
|
11 |
||
12 |
Limits |
|
13 |
--------------------------- |
|
14 |
- One queue system per user per system |
|
15 |
||
16 |
Interface |
|
17 |
--------------------------- |
|
18 |
The user should see a single command: ts |
|
19 |
The default action (maybe on "ts - ...") should be appending a job to the |
|
20 |
default queue. |
|
21 |
||
22 |
Job execution |
|
23 |
--------------------------- |
|
24 |
The jobs should receive the proper environment from the shell/parent they were |
|
25 |
queued on. |
|
26 |
The errorlevels, and maybe some statistical information (times, bytes in/out) |
|
27 |
should be stored in the queue. The user should be able to check the result of |
|
28 |
the jobs at any time. |
|
29 |
We should fork a '$SHELL' and run the job command, because a user may expect his |
|
30 |
shell parser. |
|
31 |
||
32 |
Queues |
|
33 |
--------------------------- |
|
34 |
There should be different queues, each with an id. The command will work by |
|
35 |
default with one quue. |
|
36 |
Each queue will have jobs in different states: |
|
37 |
- running |
|
38 |
- queued |
|
39 |
- blocked (wrong errorlevel on the previous job? optional) |
|
40 |
- finished (the user can see the errorlevel,etc.) |
|
41 |
||
42 |
Input/output |
|
43 |
--------------------------- |
|
44 |
The user, when adding a job to the queue, should be able to choose: |
|
45 |
- Where the output goes. As flags: |
|
46 |
- store: put it into a file in /tmp (or similar). |
|
47 |
- mail: put it into a file in /tmp, and send it by mail (maybe gzipped) |
|
48 |
- gzip: directly gzip the output |
|
49 |
- tail: store in a buffer the last 10 lines |
|
50 |
A user may choose "mail || gzip", and the file should be mailed gzipped. Or |
|
51 |
"gzip || tail", and the file should be stored directly gzipped, although with |
|
52 |
tailing available. |
|
53 |
- What to do with the input: opened/closed |
|
54 |
If opened, the user should be able to connect its current stdin to the |
|
55 |
process'. |
|
56 |
||
57 |
Job management |
|
58 |
--------------------------- |
|
59 |
- Shutdown: stop all the background processes related to the queues. |
|
60 |
- tail (id): 'tail' the last lines of a process' output. |
|
61 |
- list: list the queues, with relevant information |
|
62 |
- wait (id)*: block until some processes dies |
|
63 |
- remove (id)+: remove jobs from the queue |
|
64 |
- clear: remove the information about dead jobs (errorlevels, etc.) |
|
65 |
||
66 |
||
67 |
---------------------------------- |
|
68 |
Implementation |
|
69 |
------------------------------------ |
|
70 |
||
71 |
Client/Server |
|
72 |
---------------------- |
|
73 |
A central server daemon will have the main list of jobs, will open a socket, |
|
74 |
and all the clients will tell what to do through it. |
|
75 |
This daemon will be started , if a client cannot find it. |
|
76 |
The client will go immediatly to background when the user adds a new job. |
|
77 |
A minimum version control should be done between client/server, to assure the |
|
78 |
dialog will be correct. |
|
79 |
||
80 |
Connections |
|
81 |
----------------------- |
|
82 |
The connections could go through a Unix socket in /tmp, as X windows. |
|
83 |
An env variable could have a preference for a socket other than the default. |
|
84 |
Let's say, /tmp/ts-$USER-0.socket |
|
85 |
||
86 |
Protocol |
|
87 |
----------------------- |
|
88 |
The clients should pass messages to the server, and vicerveza. |
|
89 |
Some messages should allow: |
|
90 |
- new job |
|
91 |
- list jobs |
|
92 |
- input data |
|
93 |
- tail data |
|
94 |
- get job info |
|
95 |
- wait job |