Bugzilla – Bug 305
FAQ: autotool package structure
Last modified: 2012-04-11 21:16:13 CEST
While "autolib" is somewhat stable, the situation in "tool" is messy, and it changed over time. Here's a layout of the packages (and you can do "cabal install" in each): ------------------------------------------------------------------------------- tool/interface: defines the programmatic API (Challenger.Partial) for task types. tool/collection: (depends on interface) contains implementation of task types, so that is where the "semantics" sits, and it is a huge package (> 700 modules). tool/db: (depends on interface and collection) the "classical" autotool: database of student and task data, and a web frontend. Everything in one big executable (autotool-super.cgi) tool/test: (depends on interface, collection, db) extract test cases (task instances, student solutions, autotool answers) from the data base and file system, recomputes the results, and generates reports. tool/server: (depends on interface, collection) XML-RPC server built during the autolat project. this is a stateless server (just the semantics, no database) tool/client: (no dependencies) client that accesses a remote XML-RPC-server. the client is stateless as well, not database, no user data. It just exemplifies how to call the server methods. ----------------------------------------------------------------------- the above is the situation at the start of the "classic-via-rpc" branch, around this commit: http://autolat.imn.htwk-leipzig.de/gitweb/?p=tool;a=commit;h=6377095f59a096120768e7a256bf8e09267f7440 the plan for the near future is to remove the source-code dependency from tool/db to tool/collection: the task semantics should not be compiled-in, but provided by a remote XML RPC server (and that actually explains the branch name).
And here is some motivation behind "classic-via-rpc": 1. makes it easier to develop and test new task types (don't have to re-compile the world, but can set up an extra XML RPC server that just provides the experimental tasks under development) 2. the client program (web interface) then is not expected to change frequently, so it can be deployed at the user's sites (just need to set up the data base), and this also removes the long-standing unsettled problem of transmitting and storing student data between universities. Of course it may also create problems: 3. slower response on the client side, since there is additional network communication 4. exchange of task configurations is no longer possible between different clients. (because task configs sit in the database, which will be per-client.) So we need some means for export/import of task configs (but that's already been prepared in the autolat project).
as of this commit: http://autolat.imn.htwk-leipzig.de/gitweb/?p=tool;a=commit;h=17f19630f924aaab75845dd79e2dd558bcf38046 the tool/server package has been split into: tool/server-interface (small) tool/server-implementation (small, but depends on tool/collection which is huge) with the consequence that tool/db (the "classic" web interface) now depends only on server-interface (and thus not on tool/collection, so it can be compiled independently)