The semantic idea was that when you SELECT data the person who selects data gets a limited period of time to see the data.
An example is if I inserted 5 records, and then did a "SELECT ... LIMIT 3" I would get three rows. If another user selected data after my data and did a "SELECT ... LIMIT 3" they would only get two records (and this would be the 4th and 5th record).
Right now the period of "exclusion" for reading a record is 60 seconds. Anyone can always fetch and delete a record based on primary key (and you would want to delete records before the 60 seconds are up if you want them removed from the queue). Using triggers you can use a queue table to control for instance the data in an Innodb table.
For those who need a queue service this should hopefully make a lot of sense, for anyone else it probably sounds pretty confusing :)
Here is the tarball I put together:
From revision control:
This is not a project I am planning on putting a lot of energy in. It is highly useful though, so I will happily except patches (at the moment the code is only safe on a single CPU system BTW). I've had a number of people comment on it/play with it, so I thought it would be good to clean up the code a little for others.
While I have a need for this, it is not a pressing need.
One final thought, think of this as a service for other engines. I do not see a reason at the moment to make the engine durable, with triggers you really can use any engine as the durable store. The original plan for "partitioning" was to make it a similar service. Not all new storage engines need to be stand alone "engines", I believe there is market place for extensions to current engines.