ApCoCoA-1:ApCoCoA Server Requirements

(This page is intended as a general scratchpad for any idea concerning a future ApCoCoA server.)

Goals

During the last months, we came up with the following requirements and wishes which should be incorporated into a future ApCoCoA server:

• Get a fully functional server side, thereby enabling loose coupling of GUIs and server.
• Standardized robust XML communication from and to the server.
• Introduce a certain degree of parallelism as demonstrated by the border basis framework.
• Introduce an extensible and flexible persistency layer usable by all parts of (Ap)CoCoA.
• Introduce a framework that makes it easy to incorporate external CA software.
• Introduce a comfortable help system.
• Get as large parts as possible under GPLv3.

Ideas for the Design

Ideally, the design of a future ApCoCoA server would roughly look as follows:

                                                                Plugin-Layer
                                                                    | |
                                                                    |+|  -  CoCoA
   Client(GUI)   <==== XML ===>   Server ---- CoCoAL Interpreter  - |+|  -  ApCoCoA
                                    (sessions)                      |+|  -  <further external CA software>
                                                                    | |
                                                           ===================
                                                              Persistency

Well, actually this might not be the ideal design. The XML send in the above situation essentially contains CoCoA code. This XML would be understood by no other server in the world than ours. However, considering the SCSCP project (http://www.symbolic-computation.org/), one would ideally want a server that provides essentially remote procedure calls, i.e., the interpreter would rather go to the left hand side of the XML communication:

                                                                Plugin-Layer
                                                                    | |
                                                                    |+|  -  CoCoA
   Client(GUI) ---- CoCoAL Interpreter  <==== XML ===>   Server   - |+|  -  ApCoCoA
                                          (sessions)                |+|  -  <further external CA software>
                                                                    | |
                                                           ===================
                                                              Persistency

To get a functional, responsive, error save server, we have to introduce session management to the server (timeout handling, authentication, exchange of information, variables, states, etc. between sessions, session pool)

Things also to keep in mind, open for discussion. From this list, we will derive the components of the design in more detail:

• Logging.
• Handling the IO of CoCoAL-programs (what happens if the client becomes unavailable -> IO buffers needed, limit the amount of stored lines by some session variable; handling huge amounts of output).
• Session handling: associate a reconnecting client with its previous session.
• Handling of gnuplot must be client side, how do we handle this at different stages.
• Identify computations that have to be started in separate threads by the interpreter.
• The history should be stored in the session (I start a long computation from computer A, then come back tomorrow, work from computer B. Of course, I would like to continue where I left yesterday; How does the session know, that "its" client is B today?)
• Session initialization: If there still is a session, get information about it.
• While there is some long computation running, the client should be able to aks about the state of the computation.

Client-Server Communication

• The server should be responsive, i.e., even if some computation is running, it should take requests and give responses.
• Each message instantiated by a client gets an immediate response from the server, indicating success or errors.
• Messages might be instantiated by the server, namely, that a certain computation has finished.
• There are several types of messages a client can instantiate:
  • Configuration messages, i.e., messages that affect the behaviour of the server in any way (set timeout, etc).
  • Computation messages, i.e., messages that might take some time to finish