created: 1244047031|%e %B %Y, %H:%M
Commit 231aeeb: Making the queue API work nicely
Having prototyped the queue API, it looks clumsy. We'll make these improvements:
- Make the create and fetch methods work like constructors, returning a reference to a newly created object, if successful.
- Use link counting on the xump_queue object, so we can use unlink instead of destroy. This is nice because if we don't use new, we should not use destroy either.
- Scrap the update method, since this does nothing useful. We can add it back if needed but for now it looks like queue properties are either established at creation time, or read-only.
So while the portal request API still uses the RESTful model, the xump_queue class layers a more fluid object-oriented API on top of that. This is what the old calling code looked like (from the xump.icl selftest method):
xump_queue_t
*queue;
queue = xump_queue_new (store, "Test queue");
xump_queue_create (queue);
xump_queue_fetch (queue);
xump_queue_update (queue);
xump_queue_delete (queue);
xump_queue_destroy (&queue);
It's clear, but too different from the normal way of working with iCL objects. Having new and create, and delete and destroy is confusing. iCL lets me mark the new and destroy methods as private, so these are not exported to callers. The revised API looks more elegant:
xump_queue_t
*queue = NULL;
// Create acts as a constructor
queue = xump_queue_create (store, "Test queue");
// Unlink is an soft destructor
xump_queue_unlink (&queue);
// Fetch also acts as a constructor
queue = xump_queue_fetch (store, "Test queue");
// Delete acts as a hard destructor
xump_queue_delete (&queue);
Commit cee4083: Implemented queue_post method
I'm not sure that the message API I sketched yesterday is the right one. In any case, for sticking new messages on queues, it's not right. The model that feels right is:
- queue_post (queue, message) - post message to queue
Which fits the RESTful pattern and makes this a method of the storage layer's queue class, which is accurate. The queue is the class that knows how to organize its messages.
Here is the test case for posting messages to a queue:
// Create a queue and post messages to it
queue = xump_queue_create (store, NULL);
message = xump_message_post (queue, "address1", "abc", 4);
xump_message_unlink (&message);
message = xump_message_post (queue, "address2", "def", 4);
xump_message_unlink (&message);
xump_queue_unlink (&queue);
The store_ram implementation is pretty trivial, it'll be more fun making a file system storage layer. Several ways of doing this:
- One file per queue, with one message per line. For text messages, especially if messages are never deleted.
- One directory per queue, with one message per file. For large messages, especially for file-transfer type work. Meta data can be in separate files.
- One file per store, with queues and messages indexed into the file. Easy management of stores, and very fast if the indexes are properly designed.
Using a database like SQLite would also be fun: one table per queue, one row per message. This would probably be 10x slower than using a custom indexed file.
Rate this post:
