The OWm2 storage engine is the place where most Ambaradan magic happens. It's the real brain of the system, as everything else limits its functions to data display and interaction with both the user and other nodes in the network. Whatever you do in Ambaradan eventually boils down to a sequence of commands that are executed here.

A spoonful of history

This storage engine was originally born as an upgrade for Omegawiki (hence the OWm2 codename), but in time it has evolved to such a conceptual distance from Omegawiki that at this stage they can only be presented as remote relatives.

The most radical changes happened in the late autumn of 2008, when it became clear that most administrative problems originated from inconsistencies in the first datadesign. This forced us to produce two complete rewrites of the codebase, and it basically meant losing all the work that had been done up to then.

It was quite an unpleasant decision, as we already were sitting on a very tight schedule and there was no available funding, so the work had to be fully self-financed. At this point in time the only thing that remains of the original Omegawiki framework is the content that was stored in it, everything else was remade from scratch, including the most basic concepts behind the system.

In particular:

1. OWm2 has dropped the very idea of a defined meaning, which was central to the old design. It was a nicely intuitive concept but it generated a tremendous problem as it defined as language independent something that was actually 100% language dependent.
2. The original function of the engine was to store dictionary entries. It has evolved to a point in which it is simply a machine for storing linguistic content and for establishing relations among content parts.
3. Linguistic content is multimedia oriented from the roots. We can freely use languages that have no script and must be recorded on audio and/or video.
4. OWm2 implements a total insulation between the storage system and the GUIs. No GUI has any idea of how data is actually stored, GUIs simply use a public XML based API to communicate with an interposed daemon and simply ignore what kind of storage engine is behind it.
5. The optional co-operative structure is a peer to peer system, not a wiki. It does not require an Internet connection to work, it can be distributed on DVDs and RAM keys, it has no discussion structure and it's not community based in anyway.
6. OWm2 is focused on distributed knowledge, whereas a wiki is a centralized server.
7. The users network may edit the data you shared, but if you like your version better you can keep it, while the rest of the network keeps its evolving version.
8. While it can still serve content from a web-server, OWm2 is mainly meant to serve local offline content with asynchronous occasional connectivity, so there is no use for a mediawiki oriented storage in the project.

OWm2 in objects

Everything in OWm2 is an object, and as in all decent programming families (hopefully you got the self-ironic tone here) our objects are made of hierarchies, inherited values and behaviours.

To present such uncanny pieces of black computing magic, the usual geek convention is to start from the root element, write loads of pages on how powerful and generic it is, and then slowly get to things a simple user can understand. Too bad that most simple users have long quit reading, by the time things get to be interesting for them.

We obviously cannot build a house starting from the roof, yet we did try our best to build this guide with things that non-programmers can immediately grasp, without any need to get deeply involved in object oriented theology. You may want to read the following pages to get a good grasp of how this engine works.