created: 1243947636|%e %B %Y, %H:%M
The xump.icl class provides engine instances. These isolate some stores, not others. A RAM-based store sits inside an engine instance. A disk-based store sits outside the engine instance and can be accessed from any instance. At this stage we don't do any kind of access control. So our resource hierarchy changes a little:
Engine
+-- Store
+-- Queue
+-- Message
+-- Field
Starting on the basic framework for the store portal and plugins. We have these classes:
- xump.icl - engine class
- xump_store.icl - store portal
- xump_store_ram.icl - RAM based store stub that says hello
All single threaded, so no SMT, no multicore. That makes the classes simpler, but for any kind of performance, or when using disk-based persistence, we'll need multithreading. To be designed later.
What the stub RAM store looks like (trimming comments):
<?xml?>
<class
name = "xump_store_ram"
comment = "Xump RAM store back-end"
script = "icl_gen"
license = "gpl"
opaque = "1"
>
<inherit class = "xump_store_back" />
<method name = "announce">
icl_console_print ("I: initializing RAM-based storage layer");
</method>
</class>
And this works:
$ boom build
boom I: [Xump]: Generating files...
boom I: [Xump]: Building Xump...
$ boom test
boom I: [Xump]: Running regression tests...
This is the first running code. Not much, but it registers and calls a plugin. Committed as change 014a172.
Rate this post:
