A rewrite of CowDb and COODBMS.
Version: 0.3AgileWiki CowDb2 is a rewrite of CowDb and COODBMS, though large chunks of code will be ported from CowDb and COODBMS virtually unchanged. The COODBMS Browse client, for example, will not be changed at all.
License: Common Public License
Operating System: Linux
There will be a few architectural changes, for improved scalability, but the purpose of this rewrite is to bring clarity to the object model (i.e. Elements), as it was the object model which got gummed up during the implementation of COODBMS.
We need to begin with Rolons. You can think of them as JavaBeans, but they are composed almost entirely of framework objects. They are moderately small--so you are free to use a lot of them. But they are quite scalable--so you can build large indexes.
Rolons are the building blocks of applications and are quite comprehensive in their capabilities. Each Rolon has four sub-trees: the classifier unit, the descriptor unit, the ledger unit and the journal unit. These subtrees are in turn responsible for relations between Rolons, the behavior of the Rolon, the state of the Rolon and the history of the Rolon. A Rolon maps directly to an XML document and is composed of Elements.
Elements are the building blocks from which Rolons are constructed, but they are also used in the framework. Elements are a simple aggregate of objects, where each of these objects implements an aspect of the Element. And for each aspect there are multiple implementations to choose from. Here are the aspects which comprise an element:
* Attributes - Generally this is just simple name/value pairs, the exception being descriptor elements which support a cactus stack of attributes as well as distinguishing between working and permanent attributes.
* Contents - Contents can be either a document (as text or a byte array) or a container of other Elements and/or references to other Elements.
* Handle - Handles are used by containers to manage references to other elements. A given Element uses only a single class of handles. The handle aspect then servers as a handle factory.
* Names - Generates names. These may be ascension numbers or UUIDs.
* Rolonic - Handles navigation of rolonic structures.
* Application - This is where we can add logic specific to the use of an Element, i.e. its role in the framework or its role in the Rolon. This is also where the business logic of an application would reside. Note however that all persistent data is maintained by the attributes, contents and handle objects--application objects are not persistent! (And that really is a major point, as the framework supports navigation in past time and access to changes over time--which would be much harder to do if application logic got to persist its own data. There are only a limited number of Persistence, Attributes, Contents and Handle classes and they are all part of the framework.)
Every element has a role, which defines its usage and capabilities. The role name is also used as the XML element name when the element is expressed in an XML document. A Properties object is used to associate a class with each applicable aspect of an element, based on its role name.For example, a property to specifiy that dbRoot elements should use an instance of the CAttributes class for its attributes aspect would look like this:
dbRoot.attributes = CAttributes