--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/OBJECTIVES	Wed Mar 21 14:35:08 2007 +0100
@@ -0,0 +1,90 @@
+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