uls.co.za, as data

« Using asterisk as a RAS serverI came to realize that this is actually pretty perfect for abacus. Consider this, we have users, so we create a base called users. Then we assume the next level is the username, followed by whatever attributes we want (like team name etc …), so we could end up with user jkroon (being the admin) looking something like:Whereas a contestant could look like:Now the site itself could again look something like this:name=University of PretoriaSimple. No real glam here. A problem can be stored something like:description/contenst=#binary data#description/desc=The problem specificationsamplein/desc=sample input data in specificationsamplein/content=#more binary#The above might be slightly confusing. Basically the backend now has two calls up the database:* **get(key[, attime])** – Call to get the value (C++ string) of a key, eg db.get(“problems.Blue.files.samplein.name”) which will return the string “sample.in”.* **set(key, value[, at, serv, upkey])** – Will just set a key to a specific value, the at serv and upkey values are not important from a module perspective but can be used internally to add historic revisions when replicating. Also why we need the attime in the previous call.Other calls will be required for other purposes like finding what revisions was available etc …The client itself actually also needs to become thinner, in that most of the processing needs to happen with server modules. The server modules should have a way of telling the client what to display and how to act rather than the client being overly intelligent. Similar to a browser concept, albeit today’s browsers are pretty damn smart, it still uses javascript (coming from the server) to do what they do.This has the advantage that we can replicate the calls to set() above only. Each server will automatically add the at value as now(), it’s own server name and upkey ([serv,upkey] should be unique) before storing in the backing store and replicating.