A Weave is a navigatible object database, based on Offsider technology. Store data and/or functionality as events on the database.
Define navigation pathways between events.
Database and events respond to object messages.
Flexible CGI front-end is included.
Weave is an Offsider that acts as a navigatable object database.
You create a specific Weave by cloning the original one, and giving it a name of your choosing. Once you have a new Weave, you can set it up and customise its functionality as you require. If you give the Weave a name, this name becomes the name of the executable that you use to send messages to the Weave.
The database consists of items called events. Each event stored in the Weave is itself an Offsider, and will respond to messages. Messages can be used to modify data, or to envoke functionality associated with that event. You send a message to an event via the Weave, which then passes the message onto the particular event. Each event understands about navigation, whereby a message can be passed from one event to another until it arrives at its intended destination.
The general approach when accessing items within the Weave is first to find an appropriate entry point into the database, then to navigate around from one event to another until you find the event you are interested in, and finally to send that event a message. These steps are generally accomplished within a single message which is sent to the Weave. The first part of the message provides an entry point into the weave at some item, the second part specifies the navigation path to follow and the remainder of the message is delivered to the item of interest.
Because Weave is based on Offsider technology, it fits very comfortably into the standard Unix environment. It provides a great deal of flexibility for storing and accessing both data and functionality in a structured way.
Weave is based on Offsider technology, and is itself an Offsider object. It is persistent, and can be cloned to create new instances. All interaction with (an instance of) Weave is by means of messages. Messages can be passed from the command line, or from a programming language that supports system calls.
Weave provides its instances with a number of methods which can be extended or over-riden as required. Any programming language can be used for this purpose.
Weave events are stored as anonymous Offsiders within the Weave infrastructure. You access events by means of the various Weave and event methods supplied. In addition to the events, the Weave contains a number of child Offsiders. There is a QueueReader for ensuring data integrity, a nullEvent which handles the case where a user attempts to navigate outside the valid event domain, and namedEvents, which provides a lookup table of names for specific events of importance or interest. There is also an offsider called templates which holds a collection of offsiders that can act as templates for events. When looking for a method, each event will look to its templates as part of its search.
Weave databases are already being used in production settings, but the decision to do so must be made with care and due diligence.
One consideration is the amount of skill and experience you have in the use of the Weave, QueueReader and Offsider technologies. The other is the amount of time you can spend on maintenance and administration. Weave is not a mature technology, and nor is it well understood. You will be a pioneer, and you should not expect the road forward to be well-mapped or smooth.
Offsiders in general, and the Weave in particular, provides a lot of flexibility for the system designers. This also means that you have ample opertunity to wreak havoc if you get it wrong. It is quite possible to create Weaves that have extremely complex internal structures. You need to be careful that you are not biting off more than you can chew.
There are situations where you will need to consider the possibility of data loss. Apart from errors in your application code, or where you manually corrupt the database, there are two specific cases where the Weave can be damaged. If you are using the QueueReader, then loss of data is not such an issue, because the data can be recovered from the QueueReader. Much more serious is the potential for the corruption of the event navigation pointers.
The most serious and intractible problems will occur in the event of the hard-drive filling up. In this situation, you may well sustain multiple problems effecting many events. You may never be able to untangle it.
Less serious is the situation where you experience a sudden power failure. In this situation (provided you are using the QueueReader), at most one request will be effected. From the QueueReader audit trail, you will be able to determine which request was being processed, and also whether it completed or not. You may be able to either complete the request by hand, or back it out by hand and replay the request.
In any case, it would be wise to take regular backups of the entire database. In the event of catastrophy, it is possible (although tedious), to procede as follows:
1. take a copy of the QueueReader queue and audit trail.
2. restore the database from the most recent backup.
3. compare the restored QueueReader queue with the copy from the damaged database. Determine which requests are in addition to those pending in the restored queue.
4. add all the additional requests to the restored queue.
5. restart the QueueReader on the restored database.
Provided no database updates were done without using the QueueReader, this should restore the database to its proper status.
In summary, I suggest you start small, and start simple. Don't use the Weave for critical production components, or to store important data until you have lots of experience, and trust both the technology and your ability to manage it. Have a backup and recovery plan and use it. Finally, if you are interested in this technology, then build as many diffent databases as you can, and use them. Experience is the key to understanding and appreciating this technology.