created: 1243947830|%e %B %Y, %H:%M
This single threaded version will let us prototype the APIs. For now, the APIs will be synchronous, that is, the caller requests something, and gets a response when the work has been done. The called object and the calling object occupy the same thread.
Let's explore the queue-message-field API further. We define this API as portal requests in the xump_store.icl class. Roughly:
- queue_create (&queue, name) - create queue in store
- queue_fetch (&queue, name) - fetch queue object
- queue_update (queue) - update queue from object
- queue_delete (queue) - delete queue
- message_create (&message, queue, address, bucket) - create message in queue
- message_fetch (&message, index) - fetch message object by index
- message_update (message) - update message from object
- message_delete (message) - delete message
- field_create (&field, message, name, value) - create field in message
- field_fetch (&field, message, name) - fetch field object
- field_update (field) - update field from object
- field_delete (field) - delete field
This mirrors a RESTful model, in which a remote resource (in this case, on the other side of the API call) is managed by doing create/retrieve/update/delete on a representation of that resource (in this case, an object). In a classic OO model, the resource and the object would be the same thing. Here, they are not.
The reasons for this not-quite-OO design:
- It lets us define resources that have different life cycles than objects, which we need to define persistent resources (that remain alive when the application stops).
- It lets us do concurrent access to shared resources in a safe fashion.
- It lets us hide the implementation of the resources from the calling application.
The word "retrieve" is annoying to type, so I'll use "fetch" instead. The more often we use a word, the shorter and simpler it should be.
Commit 7e30756: Constructing the portal queue API.
To make it simple, the engine has a single store instance which is just the 'store' property. This is not a full design. We'd want to make at least one store instance per backend, but in fact allow the caller to create an arbitrary number of store instances, referenced by name. We'll add that later.
How this works now - this is from the xump.icl selftest method:
// Create an engine instance
xump_t
*xump;
xump = xump_new ();
// Create a queue object within single store
xump_queue_t
*queue;
queue = xump_queue_new (xump_store (xump), "Test queue");
// Check that every methods fails properly
assert (xump_queue_create (queue) == -1);
assert (xump_queue_fetch (queue) == -1);
assert (xump_queue_update (queue) == -1);
assert (xump_queue_delete (queue) == -1);
// Destroy queue object and engine instance
xump_queue_destroy (&queue);
xump_destroy (&xump);
Running the create method a billion times takes around 7.5 seconds on a 3GHz core. So, about 130M requests/second, 7.5 nanoseconds per request. No bottleneck here, yet, synchronous portals are fast.
Commit 5f06b01: Engine now supports multiple store registration/lookup
Added two methods to the engine, which let the caller register and lookup stores. It's more sensible that the caller creates the store portal, since it knows what extensions it is using. The API for creating and registering a new store is short and sweet:
xump_register_store (xump, xump_store_ram__xump_store_new (NULL, storenamegoeshere));
I called the methods 'register_store' and 'lookup_store' because the object_verb form I'd usually prefer ('store_register' and 'store_lookup') suggest that these methods are in the store class, which they are not.
Commit 9f9a1c2: Improved engine store method names
Actually, on second thoughts, it's even nicer to make the store list look like a property of engine, and use the same style as we use for opaque object properties, namely "set_property" and "property". This gives us a readable:
xump_set_store (xump, xump_store_ram__xump_store_new (NULL, "RAM1"));
xump_set_store (xump, xump_store_ram__xump_store_new (NULL, "RAM2"));
assert (xump_store (xump, "RAM1") != NULL);
assert (xump_store (xump, "RAM0") == NULL);
Rate this post:
