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:

                                                                  +- CoCoA
   Client(GUI)   <==== XML ===>   Server ---- CoCoAL Interpreter -+- 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.