Tool objectives

---------------------------

- Be able to send commands to the computer, so that they run one after another,

  stored in a queue.

- Control what to do with the input/output of those programs

Limits

---------------------------

- One queue system per user per system

Interface

---------------------------

The user should see a single command: ts

The default action (maybe on "ts - ...") should be appending a job to the

default queue.

Job execution

---------------------------

The jobs should receive the proper environment from the shell/parent they were

queued on.

The errorlevels, and maybe some statistical information (times, bytes in/out)

should be stored in the queue. The user should be able to check the result of

the jobs at any time.

We should fork a '$SHELL' and run the job command, because a user may expect his

shell parser.

Queues

---------------------------

There should be different queues, each with an id. The command will work by

default with one quue.

Each queue will have jobs in different states:

- running

- queued

- blocked (wrong errorlevel on the previous job? optional)

- finished (the user can see the errorlevel,etc.)

Input/output

---------------------------

The user, when adding a job to the queue, should be able to choose:

- Where the output goes. As flags:

  - store: put it into a file in /tmp (or similar).

  - mail: put it into a file in /tmp, and send it by mail (maybe gzipped)

  - gzip: directly gzip the output

  - tail: store in a buffer the last 10 lines

  A user may choose "mail || gzip", and the file should be mailed gzipped. Or

  "gzip || tail", and the file should be stored directly gzipped, although with

  tailing available.

- What to do with the input: opened/closed

  If opened, the user should be able to connect its current stdin to the

  process'.

Job management

---------------------------

- Shutdown: stop all the background processes related to the queues.

- tail (id): 'tail' the last lines of a process' output.

- list: list the queues, with relevant information

- wait (id)*: block until some processes dies

- remove (id)+: remove jobs from the queue

- clear: remove the information about dead jobs (errorlevels, etc.)

----------------------------------

Implementation

------------------------------------

Client/Server

----------------------

A central server daemon will have the main list of jobs, will open a socket,

and all the clients will tell what to do through it.

This daemon will be started , if a client cannot find it.

The client will go immediatly to background when the user adds a new job.

A minimum version control should be done between client/server, to assure the

dialog will be correct.

Connections

-----------------------

The connections could go through a Unix socket in /tmp, as X windows.

An env variable could have a preference for a socket other than the default.

Let's say, /tmp/ts-$USER-0.socket

Protocol

-----------------------

The clients should pass messages to the server, and vicerveza.

Some messages should allow:

- new job

- list jobs

- input data

- tail data

- get job info

- wait job