ApCoCoA-1:ApCoCoA Server Requirements

From ApCoCoAWiki
Revision as of 13:33, 6 March 2009 by S schuster (talk | contribs) (New page: (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 wich ...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

(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 wich should incorporate into a future ApCoCoA server:

  • Get full functionality server side, thereby enabling loose coupling of GUIs and server.
  • Standardized robust XML communication from and to the server.
  • Introduce a certain degree of parallelity as demonstrated by the boarder 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.
  • Get as large parts as possible under GPLv3.


Ideas for the Design

Ideally, the desing 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:

  • Logging
  • Handling the IO of CoCoAL-Programs (what happens, if the client becomes unavailable -> IO buffers needed; handling huge amounts of output)
  • Session handling: identify a reconecting 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 seperate threads by the interpreter.
  • ...