Architecture
The current proposal for the Agora architecture is as follows.
- Interface: a client-side application. This is how the user interacts with Agora servers.
- Client-side libraries: these libraries provide minimal functionality, like login, logout, fetch debate/argument, add/remove argument/attack/votes.
- Agora Server: databases are never directly modified by users - that would be a security nightmare. Instead, users use this interface which serves as access/privilege control. It also handles multi-server debate connections.
- Database: this stores users, arguments, attacks and votes. It can also contain meta-information, such as a hierarchical forum/subforum/thread-like meta-information.
- Outcome computation: this is any piece of software that runs periodically and/or whenever there is an update, and it simply calculates the outcome of a debate and stores it in the database. Current implementations of the algorithm handle 500 arguments in 0.2s.
In order of importance:
- All communication and protocol is encapsulated between server-side and client-side libraries/layers. This means you can easily deploy different implementations of both interfaces and servers.
- Server variants: one could implement database and a server-side interface for different underlying software, like SMF, phpBB, Tumblr, WordPress, etc. The interfaces themselves barely change: they simply check for login information in different tables, and access different underlying databases.
- Eventually, the fact that the communication protocol handles most Agora functionality will allow us to abstract away the fact that users might be looking at debates that end up spanning multiple databases and servers.
- More parts to develop and maintain. All of them should be light-weight though.