Index: trunk/Ohana/src/opihi/doc/pantasks.txt
===================================================================
--- trunk/Ohana/src/opihi/doc/pantasks.txt	(revision 7929)
+++ trunk/Ohana/src/opihi/doc/pantasks.txt	(revision 7952)
@@ -1,7 +1,12 @@
+
+- todo:
+
+  - create the processing threads:
+    - check tasks
+    - check jobs
+    - check controller  
+    - load inputs
 
 - additional issues:
-
-  - missing dependency for shell.h?
-  - should not return an error message in client if command is not found
   - server input needs to place files for input on a stack which is 
     actually loaded by the RunScheduler loop
@@ -10,39 +15,7 @@
     be running multicommand, but it probably does not hurt.
     (the client is not allowed to send ';' to the server)
-  - the multicommand needs to be available in the 'for' and other loops
-    this probably means unifying the client and non-client forms.  
-    how does multiclient get the value of the server?  I tend to use
-    globals for things like that, which is probably not the best 
-    practice.  is the client form of the tool generic? are there other
-    circumstances which would use a client/server beyond pantasks?
-    maybe pcontrol?  
 
-    the two pieces of information which need to be carried to the
-    multicommand and command functions in client/server mode are the 
-    server socket and the verbosity of the error messages.  these could
-    be defined on startup with globals and an init function of some sort.
+  - pantasks input: this passes an 'input' command to the server, which
+    performs the input in a different thread.  is this the same thread
+    as the scheduler loop?  another option within the scheduler loop?
 
-I need to do some serious work on the output messages in order 
-to support the client/server interactions.  In client/server mode,
-all of the output messages to be sent back to the client need to be
-saved in a buffer and then pushed back to the client after the command
-is executed.  Currently, I can select only the output file pointer.
-this is not sufficient.  I need to supply a function which will write to 
-an internal buffer until a 'dump' function is called, or something
-equivalent.  
-
-in client/server mode, the commands issues by the client (except as noted 
-below) all return immediately.  The output produced by those commands
-is saved by the server until the command is finished, then the
-resulting buffered data is pushed back to the client.  There a few
-commands which behave a bit differently.  these commands are in the
-background thread of the scheduler.  the resulting output is sent to
-the logger device of the scheduler rather than back to any specific
-client.  should there be a way for the client(s) to examine the
-scheduler output? 
-
-- pantasks input: this passes an 'input' command to the server, which
-  performs the input in a different thread.  is this the same thread
-  as the scheduler loop?  another option within the scheduler loop?
-
-- run